[flagged]
The Safari bug that never was (2022)
31–40 of 94 posts
Re: The Safari bug that never was (2022)
#32FTA: “And in the font we use on GOV.UK, the new line character has a bigger width than a space character – which is apparently unusual.
[…]
One of them incorrectly used the width of the new line character in its calculations, and so the box that it made was too small.”
I don’t understand that explanation. If the newline character in the font is wider than a space, why would the box end up too small if width calculations assume a newline will be rendered where the actual page will use a space?
(full bug report is here: https://github.com/alphagov/reported-bugs/issues/66, but I don’t think see it linked with a WebKit issue)
Re: The Safari bug that never was (2022)
#33Earlier quoted context omitted.
> IIRC WebKit has its own bug tracker, hence why you get better response times. Radar itself is still a terrible and demoralizing experience (from a developer point-of-view) The funny thing though is that Apple still sends WebKit bugs into Radar to work on them: https://bugs.webkit.org/show_bug.cgi?id=232939#c6
That isn’t surprising. Even if the work is being done publicly, it still needs to be tracked and project-managed internally by the team.
> Even if the work is being done publicly, it still needs to be tracked and project-managed internally by the team.
bugs.webkit.org is literally a bug tracker.
The only relevant difference between Radar and WebKit Bugzilla is private vs. public.
Re: The Safari bug that never was (2022)
#34Earlier quoted context omitted.
> and remains nameless WebKit is open-source, so it is actually one of the few Apple projects where the developers do not not remain nameless (the other big one being Swift). > the black hole that's called Radar IIRC WebKit has its own bug tracker, hence why you get better response times. Radar itself is still a terrible and demoralizing experience (from a developer point-of-view)
> IIRC WebKit has its own bug tracker, hence why you get better response times. Radar itself is still a terrible and demoralizing experience (from a developer point-of-view) The funny thing though is that Apple still sends WebKit bugs into Radar to work on them: https://bugs.webkit.org/show_bug.cgi?id=232939#c6
Webkit bugs do not get transferred to radar to be worked on. Assuming the bug is actually in webkit (eg not a bug in the safari app or an underlying system framework), all the work happens in the public bug database. Code review, patch dev, etc for webkit occurs in bugzilla.
There are many reasons for linking bugzilla bugs to radar, but the big ones are scheduling, other project dependencies inside Apple, security reports (so that reporters can be mentioned in release notes, etc).
The important thing is that the b.w.o->radar cross referencing is not for development specifically.
Re: The Safari bug that never was (2022)
#35Earlier quoted context omitted.
> IIRC WebKit has its own bug tracker, hence why you get better response times. Radar itself is still a terrible and demoralizing experience (from a developer point-of-view) The funny thing though is that Apple still sends WebKit bugs into Radar to work on them: https://bugs.webkit.org/show_bug.cgi?id=232939#c6
Webkit bugs do not get transferred to radar to be worked on. Assuming the bug is actually in webkit (eg not a bug in the safari app or an underlying system framework), all the work happens in the public bug database. Code review, patch dev, etc for webkit occurs in bugzilla. There are many reasons for linking bugzilla bugs to radar, but the big ones are scheduling, other project dependencies inside Apple, security re…
> all the work happens in the public bug database. Code review, patch dev, etc for webkit occurs in bugzilla.
What about discussion?
Do you claim there is no private discussion among Apple engineers about WebKit bugs that have been put "InRadar"?
I see a lot of WebKit bugs that have no discussion whatsoever and just seem to arrive ex nihilo from Radar. You wonder what the reasoning or explanation is for a certain code change, and you'll find absolutely nothing about it in the Bugzilla.
Re: The Safari bug that never was (2022)
#36Earlier quoted context omitted.
That isn’t surprising. Even if the work is being done publicly, it still needs to be tracked and project-managed internally by the team.
> Even if the work is being done publicly, it still needs to be tracked and project-managed internally by the team. bugs.webkit.org is literally a bug tracker. The only relevant difference between Radar and WebKit Bugzilla is private vs. public.
No. B.w.o has no release tracking, it has no ability to track dependencies on other Apple projects, etc
B.w.o is where bug fixes happen, no more. Code dev and review has to happen in b.w.o by the webkit community rules, not radar.
Re: The Safari bug that never was (2022)
#37I like how they were too modest to post the developer's comment in the bug: > "Also, this is a fantastic bug report. I don't know if I've ever seen a bug report this detailed before." Little things like that restore faith in humanity.
Agreed! The title of the post emphasizes the satisfying outcome, but the details about the journey are equally satisfying. That compliment is a reflection of that and it's good they acknowledged it.
Re: The Safari bug that never was (2022)
#38FTA: “And in the font we use on GOV.UK, the new line character has a bigger width than a space character – which is apparently unusual. […] One of them incorrectly used the width of the new line character in its calculations, and so the box that it made was too small.” I don’t understand that explanation. If the newline character in the font is wider than a space, why would the box end up too small if width calculati…
That GitHub issue has a link labeled upstream bug pointing to:
https://bugs.webkit.org/show_bug.cgi?id=232939
Not sure if that helps answer your question though
Re: The Safari bug that never was (2022)
#39These types of text metrics bugs show up in my code over and over and over and over again. I keep making them! When I was working on the icon view in Finder, icon layout, multi-line icon labels, additional info text and anything else using metrics would constantly be in danger of collapsing. Was this because I was a sloppy coder? Maybe... but the whole stack is so finicky and brittle and filled with some many special cases and different ways of getting layout measured it takes a lot of work to get all of the edge cases covered.
It isn't just Apple of course. I encountered almost the exact same bugs working on Nautilus at Eazel and various projects at Be. And in PowerPlant, and the Think Class Library and MacApp and... the list goes on.
My current music notation project pushed me to try and make multiple font support and layout as robust as possible, but I keep getting burnt! Text layout and metrics is just a difficult area.
Re: The Safari bug that never was (2022)
#40I love these kind of bug-hunting stories. The Apple engineer that fixed the bug (and remains nameless), provided an explanation, which happily surprised me. I usually read wry remarks on Twitter about the black hole that's called Radar.
As someone who’s worked in a role supporting a high ratio of people to developers in animation production, I often wonder how much of the radar black holeness is just a ratio issue.
Afaik Apple runs really small teams versus other companies. I know when I once interviewed around FAANG, the Apple teams were significantly smaller (like 5x smaller in some cases…probably also why they aren’t part of this mass tech layoffs). I used to find in my old film job that no matter how much I churned through tickets , there was just no getting out from the stigma of being unresponsive because the person on the other end of the ticket can’t see what your workload and priorities are like. That’s not to say Apple isn’t at fault for having small teams, but I think a lot of people assume the engineers themselves don’t care to fix stuff.
Though at least in my case, I could tell my users that I was working on stuff and to expect it at some time in the future. I assume Apple’s engineers are even more hamstrung by their extreme secrecy. I know the few feedback radars I’ve gotten responses from were basically “can reproduce” to “fixed in the latest OS release” without any feedback in between.
anyway all that is to say, I often see people blame the engineers (you didn’t but I see others do) whereas I think it’s a corporate culture issue that engineers are beholden to.