The Safari bug that never was (2022) • Hacker News Board

Re: The Safari bug that never was (2022)

#41

Post by dagmx » Sat, Jan 07, 2023, 7:29 PM UTC

lapcat wrote: post #33

marcellus23 wrote: post #29

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

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?

Re: The Safari bug that never was (2022)

#42

Post by lapcat » Sat, Jan 07, 2023, 7:30 PM UTC

dagmx wrote: post #40

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.

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

> I know the few feedback radars I’ve gotten responses from were basically “can reproduce”

Wait, you get "can reproduce" responses???

I never get that, I think literally never in over 15 years, but it would be a vast improvement to my bug reporting experience.

Re: The Safari bug that never was (2022)

#43

Post by dmitriid » Sat, Jan 07, 2023, 7:30 PM UTC

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 working on gov.uk design system are absolutely amazing.

Re: The Safari bug that never was (2022)

#44

Post by dagmx » Sat, Jan 07, 2023, 7:36 PM UTC

lapcat wrote: post #42

dagmx wrote: post #40

Earlier quoted context omitted.

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

> I know the few feedback radars I’ve gotten responses from were basically “can reproduce” Wait, you get "can reproduce" responses??? I never get that, I think literally never in over 15 years, but it would be a vast improvement to my bug reporting experience.

I should say it’s usually

1. Submit bug 2. Get a cannot reproduce , please provide more information 3. Submit more info as requested 4. “Okay we can reproduce. Thanks” 5. Nothing for ages 6. Okay it’s fixed

Step number 5 almost always aligns with their OS release (point and major) schedules in my experience. macOS 13.1 just came out so if I filed a minor bug now, I’d probably not hear anything till June (WWDC) or if I’m lucky, in one of the point releases that happens every couple months.

Re: The Safari bug that never was (2022)

#45

Post by zagrebian » Sat, Jan 07, 2023, 7:41 PM UTC

Key part:

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

Re: The Safari bug that never was (2022)

#46

Post by lapcat » Sat, Jan 07, 2023, 7:41 PM UTC

dagmx wrote: post #44

lapcat wrote: post #42

Earlier quoted context omitted.

> I know the few feedback radars I’ve gotten responses from were basically “can reproduce” Wait, you get "can reproduce" responses??? I never get that, I think literally never in over 15 years, but it would be a vast improvement to my bug reporting experience.

I should say it’s usually 1. Submit bug 2. Get a cannot reproduce , please provide more information 3. Submit more info as requested 4. “Okay we can reproduce. Thanks” 5. Nothing for ages 6. Okay it’s fixed Step number 5 almost always aligns with their OS release (point and major) schedules in my experience. macOS 13.1 just came out so if I filed a minor bug now, I’d probably not hear anything till June (WWDC) or if…

I never get step 4. ¯\_(ツ)_/¯

Re: The Safari bug that never was (2022)

#47

Post by dagmx » Sat, Jan 07, 2023, 7:42 PM UTC

lapcat wrote: post #46

dagmx wrote: post #44

Earlier quoted context omitted.

I should say it’s usually 1. Submit bug 2. Get a cannot reproduce , please provide more information 3. Submit more info as requested 4. “Okay we can reproduce. Thanks” 5. Nothing for ages 6. Okay it’s fixed Step number 5 almost always aligns with their OS release (point and major) schedules in my experience. macOS 13.1 just came out so if I filed a minor bug now, I’d probably not hear anything till June (WWDC) or if…

I never get step 4. ¯\_(ツ)_/¯

Probably highly dependent on the teams too

Re: The Safari bug that never was (2022)

#48

Post by jiveturkey » Sat, Jan 07, 2023, 7:46 PM UTC

i think these are the same team that has the post about why html number input is bad?

to think, such amazing work from government. at least in US we tend to think these are not the most highly skilled people

Re: The Safari bug that never was (2022)

#49

Post by thehappypm » Sat, Jan 07, 2023, 8:07 PM UTC

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 bounding box, correctly, was set to the width without a newline. The text itself reported a width including the newline. So the text was wider than the bounding box. I think.

Re: The Safari bug that never was (2022)

#50

Post by MBCook » Sat, Jan 07, 2023, 8:09 PM UTC

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