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

81–90 of 94 posts

Re: The Safari bug that never was (2022)

#81

Post by saagarjha »

dagmx wrote: post #41
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.

There’s also a difference between WebKit (the open source code) and Safari (the closed source software) I assume internally they’re treated as one component which makes it easier to mirror bugs into radar?

WebKit has a closed source component that ships alongside Safari, which is entirely closed source.

Re: The Safari bug that never was (2022)

#82

Post by saagarjha »

mproud wrote: post #67
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…

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.

Snakes on a Radar is always a fun list to peruse.

Re: The Safari bug that never was (2022)

#83

Post by saagarjha »

olliej wrote: post #74
lapcat wrote: post #35

Earlier quoted context omitted.

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

> What about discussion? Is achieved by talking among each other, or simply by knowing how to fix/implement the feature (not every bug requires any discussion at all). Either in person (which would be inherently "private" as you say), or irc historically - I'm unsure whether irc is still significant as I recall free node dying off or something a few years back? > Do you claim there is no private discussion among Appl…

> The lack of explanation is typically because the engineers working on changes have the context for why a change is needed, so don't include an explanation.

Part of which is because the engineers are working on an unreleased feature that they’d like to put up “quietly”.

Re: The Safari bug that never was (2022)

#84

Post by saagarjha »

madeofpalk wrote: post #70
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 wid…

That is an accurate description of this code.

Re: The Safari bug that never was (2022)

#85

Post by saagarjha »

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…

> The font also has data about the newline character, including its width. This doesn’t really make sense [emphasis mine]

The font doesn’t have one width, it has a width for each character. The data for the newline character is bogus. All of these match.

Re: The Safari bug that never was (2022)

#86

Post by saagarjha »

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…

The code subtracted out the width of the newline assuming it was the same width as a space (which it had used when computing the other size).

Re: The Safari bug that never was (2022)

#88

Post by lapcat »

olliej wrote: post #79
lapcat wrote: post #75

Earlier quoted context omitted.

> I recall free node dying off or something a few years back? Yeah, a kind of hostile takeover occurred, which the IRC community did not appreciate. > Again, I think you grossly overestimate the amount of recorded "discussion" that goes with a bug. Perhaps so. Seems a bit odd to me though. And a bit lonely :-) > The lack of explanation is typically because the engineers working on changes have the context for why a c…

> Perhaps so. Seems a bit odd to me though. And a bit lonely :-) People communicate in IRC (or a public slack now based on another comment?), in person, or in email. So when needed communication happens, it's just generally back and forth commentary in a bug is not a particularly good or efficient way to discuss implementation of bug fixes, features, etc. > Well, I think it's worth noting that this is not very helpfu…

> So when needed communication happens, it's just generally back and forth commentary in a bug is not a particularly good or efficient way to discuss implementation of bug fixes, features, etc.

I disagree, because whether it's the intention or not ("it's a bug tracker being used to track bug fixes, not a tool for communicating with arbitrary people not involved in the project"), the bug report de facto becomes an important historical record for understanding the code. In the future, when someone looks back, the question that often comes to mind is "Why?" Why this (that)? Why now (then)? The motive, the historical context, is rarely something that becomes evident just looking at the code, even code with comments.

Can I change this code? Can I delete this code? How did this code ever work? You can't rely on unit tests to tell you the story behind the code. And when you come upon some "questionable" code, it's equally likely that the comments and/or tests are questionable too.

If the code was written to handle something publicly important, if debates were had, alternatives considered, choices made and rejected, that's worth knowing, in my opinion.

Re: The Safari bug that never was (2022)

#89

Post by ynniv »

hinoki wrote: post #77
diskzero wrote: post #39

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

Text layout is just hard. There’s a lot of history you need to encode as rules, and you end up with a very complicated system that is hard to abstract because there are circular dependencies all over the place. This bug was because the size of the container depends on the text, whose layout depends on the container. Text just wouldn’t look “right” if we skipped it. It’s as “human” a problem as dates and time, probabl…

"Just use Unix time!" Some problems have a surprising amount of inherent complexity. Java has tried a few times to solve date values, and the results are sometimes unusably complicated. I don't know what the answer is... an even more sophisticated type system? A linting step in the tool chain? An academic paper? An industry publication?

Hardware improves every month, but some parts of software worked better thirty years ago.

Re: The Safari bug that never was (2022)

#90

Post by epolanski »

mach1ne wrote: post #54
llimos wrote: post #17

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

People often forget that there are brilliant developers who don’t need to be 10x to produce extreme value to those around them.

Why would proper documenting and communication not be part of more effective engineering?

It's about providing 10 times the value, not churning similar quality code 10 times faster.

Post reply on HN