9 ms·

The Safari bug that never was (2022)

286 points by robin_reala 4y ago

mmis1000 4y ago
I use edge preview and firefox nightly on my dev machine as daily browser. It is sure the way to make browser bug not ends up being in you bug queue. A fix in browser itself is definitely better than a workaround in your app. Given workaround in web app is almost permanent (you just have no way to stop people from using an old browser)
rado 4y ago
Good to know they are serious about fixing things. Hopefully my bug, which crashes Safari (!) with CSS only, will be fixed soon: https://bugs.webkit.org/show_bug.cgi?id=249575 https://bugs.webkit.org/show_bug.cgi?id=249575
- freediver 4y ago
  In my experience, WebKit team has been extremely responsive.
- sccxy 4y ago
  My previous experience says that it will take several years to fix it. Just like in IE, you need to make silly workarounds.
intellix 4y ago
[flagged]
- deleted 4y ago
  [deleted]
- lapcat 4y ago
  > It's clear they hate the web I feel that they're just organizationally incompetent. They're moving too fast and lack adequate quality assurance. macOS itself is getting much buggier overall. Craig Federighi should be fired.
  - dlivingston 4y ago
    I like Federighi's public persona quite a lot, but yes, I have too been concerned about macOS's quality since he took over. Any books / inside reports I can read about his tenure that would provide more context on him & his management of macOS?
    - dieulot 4y ago
      Some engineers post about their past experiences sometimes. https://tidbits.com/2019/10/21/six-reasons-why-ios-13-and-catalina-are-so-buggy/ https://tidbits.com/2019/10/21/six-reasons-why-ios-13-and-ca... https://twitter.com/taquitos/status/1599824249107406848 https://twitter.com/taquitos/status/1599824249107406848
  - lillecarl 4y ago
    I'm not usually a backwards person, but I got the Macbook 2016, and with every release it got worse. Now I'm on NixOS on a Lenovo and while there are regressions, they're usually temporary. Regressions on MacOS seemed permanent.
- nicoburns 4y ago
  My impression is that the Safari team is just very small. They are often more quirky than other browsers, and they lag in features (but not nearly so badly as IE used to). On the other hand they've brought some very welcome improvements: the :has selector and container queries being the standout ones in recent times. And their engine is more power efficient and often faster than anyone elses. EDIT: I would add: 90% seems waaay too high. If this isn't an exaggeration then you may want to consider that you might be doing something wrong (Not checking caniuse for support before using a feature? Trying to use features that are unsupported / poorly supported by your target browsers anyway?)
  - als0 4y ago
    Really enjoying the power efficiency of Safari on a Mac, it keeps me away from the other browsers.
    - kitsunesoba 4y ago
      It’s disheartening that Google and Mozilla seem so disinterested in trying to match or exceed that power efficiency. I like having multiple options for web browsers but because of the difference is so stark it’s only actually a choice on desktops.
      - deleted 4y ago
        [deleted]
      - deleted 4y ago
        [deleted]
      - kevingadd 4y ago
        Mozilla has invested a lot of effort into power efficiency. It's a pretty painful treadmill considering how often platform-level things change (OS X compositor changes, OpenGL being killed, etc) which means you end up losing ground and having to rearchitect or rebuild stuff to get back to where you were previously. Part of Firefox's power efficiency challenges on OS X are specifically due to how Apple designed the platform, and not something wrong with the browser. They've had to incrementally add in lots of machinery to feed the OS the information it suddenly wants. If Safari has better power efficiency on OS X (I don't doubt it), that's partly just because they work next door to the video driver and OS compositor people. It's not because Mozilla doesn't care. (Does Google care? I can't say for sure, but I suspect they do.)
- Turing_Machine 4y ago
  Safari has its problems, to be sure, but it is a long, long, long way from being equivalent to old IE. On one project I remember, around 30% of the code was there simply to make it work with IE. I've never seen anything close to that with Safari (much less 90%).
  - kitsunesoba 4y ago
    I remember having to support IE versions 6-11 with a couple of sites I worked on and wondering why Microsoft wouldn't just port the technically superior Tasman engine used for IE for Mac to Windows… it was so much better than Trident at handling CSS and could do things that Trident couldn't until a decade later like properly render transparent PNGs without hacks. And yeah, Safari has posed far less of an issue for me than IE did.
- kitsunesoba 4y ago
  What sites trigger this? Have been using Safari for years and haven’t encountered such a bug.
  - intellix 4y ago
    https://www.starzsoft.com/iphone-issues/safari-crashes-after-strong-password-autofill-users-reported-after-ios-16-upgrade/ https://www.starzsoft.com/iphone-issues/safari-crashes-after... https://www.reddit.com/r/ios/comments/xjb06m/ios_16_safari_constantly_crashes_when_using_the/ https://www.reddit.com/r/ios/comments/xjb06m/ios_16_safari_c... https://discussions.apple.com/thread/254191515 https://discussions.apple.com/thread/254191515
- deleted 4y ago
  [deleted]
bartvk 4y ago
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.
- 130e13a 4y ago
  > 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)
  - lapcat 4y ago
    > 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 https://bugs.webkit.org/show_bug.cgi?id=232939#c6
    - marcellus23 4y ago
      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.
      - lapcat 4y ago
        > 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.
        olliej 4y ago
llimos 4y ago
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.
- ojintoad 4y ago
  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.
- dmitriid 4y ago
  People working on gov.uk design system are absolutely amazing.
- mach1ne 4y ago
  People often forget that there are brilliant developers who don’t need to be 10x to produce extreme value to those around them.
  - epolanski 4y ago
    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.
- epolanski 4y ago
  Bragging isn't a cultural standard around the world. Many cultures are very adverse against any kind of such boasting and cultivate modesty. UK is one of those countries where bragging is widely considered vulgar. Happens, but it's not considered or taken as the norm or polite. I think this article actually perfectly sums English bragging: it's polite and short, hidden between describing the due diligence that went behind reporting the bug and the numbers of other bugs they have reported and helped fix in time combined with a semi patronizing (but absolutely true and sharable) link to how to report bugs well. If you went further east to Asia, to cultures where any kind of boasting or bragging is seen very negatively, not just vulgar, you would've found even less of it.
deleted 4y ago
[deleted]
playingalong 4y ago
After reading "could see the strange things [...] happening in the header" I was surprised to read about font widths.
KMuncie 4y ago
Safari seems to have been getting more developer attention this last year. This is good but also has resulted in a number of bugs and regressions as they move fast. Same is happening on Chromium. I likewise have been involved in a similar bizarre bug. We wrote up a very detailed report with a reduced test case but sadly it has not received much attention. https://bugs.webkit.org/show_bug.cgi?id=247020 https://bugs.webkit.org/show_bug.cgi?id=247020
kaveen 4y ago
[flagged]
Someone 4y ago
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 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 https://github.com/alphagov/reported-bugs/issues/66, but I don’t think see it linked with a WebKit issue)
- ojintoad 4y ago
  That GitHub issue has a link labeled upstream bug pointing to: https://bugs.webkit.org/show_bug.cgi?id=232939 https://bugs.webkit.org/show_bug.cgi?id=232939 Not sure if that helps answer your question though
  - JonathonW 4y ago
    The answer to the question appears to be in comment 13; the width of the newline character is used at one point but then assumed to be the same as the width of a space later on: > I think I see. There's a block at the bottom of RenderText::computePreferredLogicalWidths() which is only hit if wordLen == 0 and !isNewline (which is the case here) which measures the width of the one character at index i and adds it to currMaxWidth. In our situation, that's the leading newline character. > Then, later, we subtract it out like this: "widths.max -= font.width(RenderBlock::constructTextRun(&space, 1, style));". This expects that the width of this initial character is equal to the width of a space.
- thehappypm 4y ago
  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.
- MBCook 4y ago
  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.
diskzero 4y ago
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 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.
- hinoki 4y ago
  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, probably worse! Your best bet is to use libraries to avoid the whole problem, but that means delegating all layout which might not be possible.
  - ynniv 4y ago
    "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.
zagrebian 4y ago
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.
jiveturkey 4y ago
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
- TazeTSchnitzel 4y ago
  The US attitude to government is a self-fulfilling prophecy. You don't give a chance to succeed to those you expect to fail.
  - jen20 4y ago
    One thing to note about GDS is that they pay comparably to many other senior dev jobs in London (and especially the rest of the UK outside of London). In the US the equivalent maxes out at barely entry level salaries for private industry.
    - brokebroadbeat 4y ago
      It looks less if you compare salary to salary, but factoring in the civil service pension means GDS staffers probably get paid more
michelb 4y ago
So nice to see this and makes me wish we had an open bug tracker with responsive developers for MacOS.
w0mbat 4y ago
Having worked on two major web browsers, I can tell you that they spend a surprisingly large proportion of their time measuring text. Drawing text is only half as much of the cycles spent. We got a significant speed boost at one point by reverse engineering an undocumented fast text measuring OS API that a rival browser was using.
Amineami114 4y ago
[dead]
deanCommie 4y ago
From the fix: https://bugs.webkit.org/attachment.cgi?id=448463&action=prettypatch 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 harder to read also. I also would have created an intermediary variable or a helper method for `character == tabCharacter ? width : font.spaceWidth()` - 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), or why the old behaviour that used `width` instead of `font.spaceWidth()` ONLY applies to tabCharacter (So it should be encapsulate inside a method with a clear comment with the info from the ChangeLog) Lastly, this diff doesn't seem to match the blog description: > The font also has data about the newline character, including its width. This doesn’t really make sense – new lines don’t (or at least shouldn’t) take up any space, but the font doesn’t treat it differently to any other character. The creator of the font still has to include a width for the new line character in the font’s data. 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. 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. Ultimately the ChangeLog doesn't match the code. I trust the blog writer, the code author, and the description of the bug in the ChangeLog. What needed improvement here then is the code to imperatively match what is described in English.
- madeofpalk 4y ago
  > 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
navels 4y ago
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 :-)
hprotagonist 4y ago
Underfull \hbox (badness 10000)
mattigames 4y ago
Let's not use "(previous year)" on titles when it's hasn't even been a week since the new year started, at least January should be free of "(2022)" tags, this early in the year those are just noise.

286 points by robin_reala 4y ago

I use edge preview and firefox nightly on my dev machine as daily browser. It is sure the way to make browser bug not ends up being in you bug queue. A fix in browser itself is definitely better than a workaround in your app. Given workaround in web app is almost permanent (you just have no way to stop people from using an old browser)

rado 4y ago

Good to know they are serious about fixing things. Hopefully my bug, which crashes Safari (!) with CSS only, will be fixed soon: https://bugs.webkit.org/show_bug.cgi?id=249575 https://bugs.webkit.org/show_bug.cgi?id=249575

freediver 4y ago
In my experience, WebKit team has been extremely responsive.
sccxy 4y ago
My previous experience says that it will take several years to fix it. Just like in IE, you need to make silly workarounds.

intellix 4y ago

[flagged]

deleted 4y ago
[deleted]
lapcat 4y ago
> It's clear they hate the web I feel that they're just organizationally incompetent. They're moving too fast and lack adequate quality assurance. macOS itself is getting much buggier overall. Craig Federighi should be fired.
- dlivingston 4y ago
  I like Federighi's public persona quite a lot, but yes, I have too been concerned about macOS's quality since he took over. Any books / inside reports I can read about his tenure that would provide more context on him & his management of macOS?
  - dieulot 4y ago
    Some engineers post about their past experiences sometimes. https://tidbits.com/2019/10/21/six-reasons-why-ios-13-and-catalina-are-so-buggy/ https://tidbits.com/2019/10/21/six-reasons-why-ios-13-and-ca... https://twitter.com/taquitos/status/1599824249107406848 https://twitter.com/taquitos/status/1599824249107406848
- lillecarl 4y ago
  I'm not usually a backwards person, but I got the Macbook 2016, and with every release it got worse. Now I'm on NixOS on a Lenovo and while there are regressions, they're usually temporary. Regressions on MacOS seemed permanent.
nicoburns 4y ago
My impression is that the Safari team is just very small. They are often more quirky than other browsers, and they lag in features (but not nearly so badly as IE used to). On the other hand they've brought some very welcome improvements: the :has selector and container queries being the standout ones in recent times. And their engine is more power efficient and often faster than anyone elses. EDIT: I would add: 90% seems waaay too high. If this isn't an exaggeration then you may want to consider that you might be doing something wrong (Not checking caniuse for support before using a feature? Trying to use features that are unsupported / poorly supported by your target browsers anyway?)
- als0 4y ago
  Really enjoying the power efficiency of Safari on a Mac, it keeps me away from the other browsers.
  - kitsunesoba 4y ago
    It’s disheartening that Google and Mozilla seem so disinterested in trying to match or exceed that power efficiency. I like having multiple options for web browsers but because of the difference is so stark it’s only actually a choice on desktops.
    - deleted 4y ago
      [deleted]
    - deleted 4y ago
      [deleted]
    - kevingadd 4y ago
      Mozilla has invested a lot of effort into power efficiency. It's a pretty painful treadmill considering how often platform-level things change (OS X compositor changes, OpenGL being killed, etc) which means you end up losing ground and having to rearchitect or rebuild stuff to get back to where you were previously. Part of Firefox's power efficiency challenges on OS X are specifically due to how Apple designed the platform, and not something wrong with the browser. They've had to incrementally add in lots of machinery to feed the OS the information it suddenly wants. If Safari has better power efficiency on OS X (I don't doubt it), that's partly just because they work next door to the video driver and OS compositor people. It's not because Mozilla doesn't care. (Does Google care? I can't say for sure, but I suspect they do.)
Turing_Machine 4y ago
Safari has its problems, to be sure, but it is a long, long, long way from being equivalent to old IE. On one project I remember, around 30% of the code was there simply to make it work with IE. I've never seen anything close to that with Safari (much less 90%).
- kitsunesoba 4y ago
  I remember having to support IE versions 6-11 with a couple of sites I worked on and wondering why Microsoft wouldn't just port the technically superior Tasman engine used for IE for Mac to Windows… it was so much better than Trident at handling CSS and could do things that Trident couldn't until a decade later like properly render transparent PNGs without hacks. And yeah, Safari has posed far less of an issue for me than IE did.
kitsunesoba 4y ago
What sites trigger this? Have been using Safari for years and haven’t encountered such a bug.
- intellix 4y ago
  https://www.starzsoft.com/iphone-issues/safari-crashes-after-strong-password-autofill-users-reported-after-ios-16-upgrade/ https://www.starzsoft.com/iphone-issues/safari-crashes-after... https://www.reddit.com/r/ios/comments/xjb06m/ios_16_safari_constantly_crashes_when_using_the/ https://www.reddit.com/r/ios/comments/xjb06m/ios_16_safari_c... https://discussions.apple.com/thread/254191515 https://discussions.apple.com/thread/254191515
deleted 4y ago
[deleted]

bartvk 4y ago

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.

130e13a 4y ago
> 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)
- lapcat 4y ago
  > 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 https://bugs.webkit.org/show_bug.cgi?id=232939#c6
  - marcellus23 4y ago
    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.
    - lapcat 4y ago
      > 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.
      - olliej 4y ago

llimos 4y ago

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.

ojintoad 4y ago
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.
dmitriid 4y ago
People working on gov.uk design system are absolutely amazing.
mach1ne 4y ago
People often forget that there are brilliant developers who don’t need to be 10x to produce extreme value to those around them.
- epolanski 4y ago
  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.
epolanski 4y ago
Bragging isn't a cultural standard around the world. Many cultures are very adverse against any kind of such boasting and cultivate modesty. UK is one of those countries where bragging is widely considered vulgar. Happens, but it's not considered or taken as the norm or polite. I think this article actually perfectly sums English bragging: it's polite and short, hidden between describing the due diligence that went behind reporting the bug and the numbers of other bugs they have reported and helped fix in time combined with a semi patronizing (but absolutely true and sharable) link to how to report bugs well. If you went further east to Asia, to cultures where any kind of boasting or bragging is seen very negatively, not just vulgar, you would've found even less of it.

deleted 4y ago

[deleted]

playingalong 4y ago

After reading "could see the strange things [...] happening in the header" I was surprised to read about font widths.

KMuncie 4y ago

Safari seems to have been getting more developer attention this last year. This is good but also has resulted in a number of bugs and regressions as they move fast. Same is happening on Chromium. I likewise have been involved in a similar bizarre bug. We wrote up a very detailed report with a reduced test case but sadly it has not received much attention. https://bugs.webkit.org/show_bug.cgi?id=247020 https://bugs.webkit.org/show_bug.cgi?id=247020

kaveen 4y ago

[flagged]

Someone 4y ago

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 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 https://github.com/alphagov/reported-bugs/issues/66, but I don’t think see it linked with a WebKit issue)

ojintoad 4y ago
That GitHub issue has a link labeled upstream bug pointing to: https://bugs.webkit.org/show_bug.cgi?id=232939 https://bugs.webkit.org/show_bug.cgi?id=232939 Not sure if that helps answer your question though
- JonathonW 4y ago
  The answer to the question appears to be in comment 13; the width of the newline character is used at one point but then assumed to be the same as the width of a space later on: > I think I see. There's a block at the bottom of RenderText::computePreferredLogicalWidths() which is only hit if wordLen == 0 and !isNewline (which is the case here) which measures the width of the one character at index i and adds it to currMaxWidth. In our situation, that's the leading newline character. > Then, later, we subtract it out like this: "widths.max -= font.width(RenderBlock::constructTextRun(&space, 1, style));". This expects that the width of this initial character is equal to the width of a space.
thehappypm 4y ago
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.
MBCook 4y ago
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.

diskzero 4y ago

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

hinoki 4y ago
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, probably worse! Your best bet is to use libraries to avoid the whole problem, but that means delegating all layout which might not be possible.
- ynniv 4y ago
  "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.

zagrebian 4y ago

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.

jiveturkey 4y ago

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

TazeTSchnitzel 4y ago
The US attitude to government is a self-fulfilling prophecy. You don't give a chance to succeed to those you expect to fail.
- jen20 4y ago
  One thing to note about GDS is that they pay comparably to many other senior dev jobs in London (and especially the rest of the UK outside of London). In the US the equivalent maxes out at barely entry level salaries for private industry.
  - brokebroadbeat 4y ago
    It looks less if you compare salary to salary, but factoring in the civil service pension means GDS staffers probably get paid more

michelb 4y ago

So nice to see this and makes me wish we had an open bug tracker with responsive developers for MacOS.

w0mbat 4y ago

Having worked on two major web browsers, I can tell you that they spend a surprisingly large proportion of their time measuring text. Drawing text is only half as much of the cycles spent. We got a significant speed boost at one point by reverse engineering an undocumented fast text measuring OS API that a rival browser was using.

Amineami114 4y ago

[dead]

deanCommie 4y ago

From the fix: https://bugs.webkit.org/attachment.cgi?id=448463&action=prettypatch 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 harder to read also. I also would have created an intermediary variable or a helper method for `character == tabCharacter ? width : font.spaceWidth()` - 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), or why the old behaviour that used `width` instead of `font.spaceWidth()` ONLY applies to tabCharacter (So it should be encapsulate inside a method with a clear comment with the info from the ChangeLog) Lastly, this diff doesn't seem to match the blog description: > The font also has data about the newline character, including its width. This doesn’t really make sense – new lines don’t (or at least shouldn’t) take up any space, but the font doesn’t treat it differently to any other character. The creator of the font still has to include a width for the new line character in the font’s data. 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. 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. Ultimately the ChangeLog doesn't match the code. I trust the blog writer, the code author, and the description of the bug in the ChangeLog. What needed improvement here then is the code to imperatively match what is described in English.

madeofpalk 4y ago
> 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

navels 4y ago

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 :-)

hprotagonist 4y ago

Underfull \hbox (badness 10000)

mattigames 4y ago

Let's not use "(previous year)" on titles when it's hasn't even been a week since the new year started, at least January should be free of "(2022)" tags, this early in the year those are just noise.