Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Safari bug that never was (2022)

obyford.com

Post reply on HN
Print view View original

61–70 of 94 posts

Re: The Safari bug that never was (2022)

#61

Post by lapcat »

marcellus23 wrote: post #59
lapcat wrote: post #33

Earlier quoted context omitted.

> 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.

> The only relevant difference between Radar and WebKit Bugzilla is private vs. public. No, this is not true. Radar is not just "a bug tracker" — it is a very powerful project management tool, custom-built over several decades for the way Apple works, with integrations into other internal tools and processes. It should be obvious why Apple wants to track work being done on Webkit using the same tool it uses to track…

Last time I saw Radar, and its source code, which was admittedly over a decade ago, it was not a "project management tool" as such, although radars could of course be used in project management. It was indeed just a bug tracker, but yes, a very powerful one. At bottom it was a giant Oracle database, with several frontends.

Re: The Safari bug that never was (2022)

#62

Post by jholdn »

Someone wrote: post #32

FTA: “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…

I think it’s just a phrasing issue. Should be: 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 [for the text size computed by the other].

I agree it makes it sounds like the box sizing was wrong when it must be the other way around.

Re: The Safari bug that never was (2022)

#63

Post by kccqzy »

bartvk wrote: post #8

I 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.

Why did you call them nameless? Their name is readily available, Myles C. Maxfield.

Re: The Safari bug that never was (2022)

#64

Post by MBCook »

Someone wrote: post #53
MBCook wrote: post #50

Earlier quoted context omitted.

The way I understood it in my head (though I don’t know if the article actually says this) is that process that figured out the box size was probably ignoring the new line and just assuming it was the same width as a space. The process that actually laid out the text was using the specified width of the new line, so it came up with a longer width and had to break the line.

But the thing is: as the article (correctly) says: “In HTML, any extra whitespace between words is ignored. This means you can add extra spaces, and even new lines, between words without affecting how they are displayed in the browser” So, “ignoring the new line and just assuming it was the same width as a space” is correct behaviour. I now think what happened is this: - the width of the box to render the text in was…

The article explicitly says the new line width was larger than the space, so I don’t think it’s your second guess.

Your first guess makes perfect sense though, so perhaps that’s what happened. As I said, that was how I had put it together in my mind (regardless of actual fact).

Re: The Safari bug that never was (2022)

#65

Post by marcellus23 »

lapcat wrote: post #61
marcellus23 wrote: post #59

Earlier quoted context omitted.

> The only relevant difference between Radar and WebKit Bugzilla is private vs. public. No, this is not true. Radar is not just "a bug tracker" — it is a very powerful project management tool, custom-built over several decades for the way Apple works, with integrations into other internal tools and processes. It should be obvious why Apple wants to track work being done on Webkit using the same tool it uses to track…

Last time I saw Radar, and its source code, which was admittedly over a decade ago, it was not a "project management tool" as such, although radars could of course be used in project management. It was indeed just a bug tracker, but yes, a very powerful one. At bottom it was a giant Oracle database, with several frontends.

I can't speak as to what Radar looked like a decade ago.

Re: The Safari bug that never was (2022)

#66

Post by navels »

I submitted a bug report to WebKit last year and was fully expecting it to sit uncommented and then closed eventually for "no activity" or any of the other outcomes that seem common with large open-source projects supported by any of the Big 5.

This was on a Wednesday. I rolled up my sleeves to start learning WebKit development myself, but they had a patch submitted, reviewed, and accepted by the next day :-)

Re: The Safari bug that never was (2022)

#67

Post by mproud »

marcellus23 wrote: post #59
lapcat wrote: post #33

Earlier quoted context omitted.

> 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.

> The only relevant difference between Radar and WebKit Bugzilla is private vs. public. No, this is not true. Radar is not just "a bug tracker" — it is a very powerful project management tool, custom-built over several decades for the way Apple works, with integrations into other internal tools and processes. It should be obvious why Apple wants to track work being done on Webkit using the same tool it uses to track…

I know a story of a person who submitted a Radar ticket for an engineer to go get a haircut.

They closed the ticket a few days later with a picture showing the issue resolved.

Re: The Safari bug that never was (2022)

#69

Post by madeofpalk »

lapcat wrote: post #35
olliej wrote: post #34

Earlier quoted context omitted.

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 cod…

> Do you claim there is no private discussion among Apple engineers about WebKit bugs that have been put "InRadar"?

Open source bugs will have private/non-public conversations (whether it's in person, or on slack, or on a seperate issue tracker) all the time. That's not abnormal or all that damning.

Re: The Safari bug that never was (2022)

#70

Post by madeofpalk »

deanCommie wrote: post #57

From the fix: https://bugs.webkit.org/attachment.cgi?id=448463&action=pret... > Reviewed by NOBODY (OOPS!). If I was reviewing the code, I would have asked why Myles changed WidthIterator.cpp's call to charactersTreatedAsSpace.constructAndAppend from a separate parameter on each line to everything inline. This change made the diff of this change harder to read, and will make the diff of any future parameter change ha…

> it's not clear at all here why this check needs to be there (without looking at the ChangeLog, which I shouldn't have to do to understand code)

Teams that standardise on in-depth change messages usually have a culture to look towards commit messages/changelogs to understand more motivation about why code is a particularly way.

> This makes it sound like the FONT is wrong and the font width shouldn't be used for width calculation. Yet the change in the code introduces using the font's space width explicitly.

I don't know C++, and I'm not familiar with the codebase, but my read of the code change says that "if it's a 'treat-it-like-a-space-character" that isn't a tab, then size the character like a space character". This is inline with the english description

Post reply on HN