[HN Gopher] The Safari bug that never was (2022)
___________________________________________________________________
The Safari bug that never was (2022)
Author : robin_reala
Score : 196 points
Date : 2023-01-07 16:06 UTC (6 hours ago)
(HTM) web link (obyford.com)
(TXT) w3m dump (obyford.com)
| w0mbat wrote:
| 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.
| llimos wrote:
| 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.
| mach1ne wrote:
| People often forget that there are brilliant developers who
| don't need to be 10x to produce extreme value to those around
| them.
| ojintoad wrote:
| 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 wrote:
| People working on gov.uk design system are absolutely amazing.
| [deleted]
| playingalong wrote:
| After reading "could see the strange things [...] happening in
| the header" I was surprised to read about font widths.
| michelb wrote:
| So nice to see this and makes me wish we had an open bug tracker
| with responsive developers for MacOS.
| bartvk wrote:
| 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.
| kccqzy wrote:
| Why did you call them nameless? Their name is readily
| available, Myles C. Maxfield.
| 130e13a wrote:
| > 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 wrote:
| > 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
| marcellus23 wrote:
| 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 wrote:
| > 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 wrote:
| 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.
| marcellus23 wrote:
| > 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 work
| being done on every other project at the company.
| lapcat wrote:
| 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.
| dagmx wrote:
| 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?
| olliej wrote:
| 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.
| lapcat wrote:
| > 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.
| dagmx wrote:
| 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.
| lapcat wrote:
| > 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.
| dagmx wrote:
| 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.
| lapcat wrote:
| I never get step 4. -\\_(tsu)_/-
| dagmx wrote:
| Probably highly dependent on the teams too
| kaveen wrote:
| [flagged]
| Someone wrote:
| 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, but I don't think see it linked with a WebKit
| issue)
| jholdn wrote:
| 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.
| ojintoad wrote:
| 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
| JonathonW wrote:
| 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 wrote:
| 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 wrote:
| 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.
| Someone wrote:
| 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 computed
| correctly
|
| - the code that then laid out the text inside that box
| incorrectly used the width of the newline in the HTML to
| compute the length of the text, concluded the text was too
| long to fit on a line, and line-wrapped it inside the box.
|
| That's not consistent with the claim from the article _"and
| so the box that it made was too small"_ , though.
|
| Alternatively, the font's line feed glyph was _less_wide_
| than a space, and the width of the box was computed as too
| small, but then the article is incorrect in that it claims
| the font's line feed glyph was _wider_ than a space.
|
| (and for those wondering why a browser needs to compute the
| width of that text twice: I wouldn't know, but browser layout
| engines are complex beasts)
| MBCook wrote:
| 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).
| yarg wrote:
| > So, "ignoring the new line and just assuming it was the
| same width as a space" is correct behaviour.
|
| That's not true?
|
| If it's a newline following whitespace then it should be
| ignored; the width should be calculated as zero, not the
| width of a space.
|
| On the other hand, if it's not following whitespace the
| width should be that of the newline character, again not
| the width of a space.
|
| Or am I misunderstanding you?
| deanCommie wrote:
| 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 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.
| zagrebian wrote:
| 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 wrote:
| 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 wrote:
| The US attitude to government is a self-fulfilling prophecy.
| You don't give a chance to succeed to those you expect to fail.
| diskzero wrote:
| 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.
| KMuncie wrote:
| 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
| rado wrote:
| 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
| freediver wrote:
| In my experience, WebKit team has been extremely responsive.
| sccxy wrote:
| My previous experience says that it will take several years to
| fix it.
|
| Just like in IE, you need to make silly workarounds.
| intellix wrote:
| [flagged]
| lapcat wrote:
| > 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.
| carlhjerpe wrote:
| 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.
| dlivingston wrote:
| 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 wrote:
| Some engineers post about their past experiences sometimes.
|
| https://tidbits.com/2019/10/21/six-reasons-why-ios-13-and-
| ca...
|
| https://twitter.com/taquitos/status/1599824249107406848
| [deleted]
| nicoburns wrote:
| 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 wrote:
| Really enjoying the power efficiency of Safari on a Mac, it
| keeps me away from the other browsers.
| kitsunesoba wrote:
| 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]
| [deleted]
| kevingadd wrote:
| 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.)
| kitsunesoba wrote:
| Part of the difference is compositor integration for
| sure, but there's also design decisions that factor in,
| like how Safari has throttled JS in non-active tabs for
| years, where Chrome only started doing this last year.
| One gets the impression that Google at least is more
| concerned with Chrome being an attractive app platform
| than they are with it being responsible with user
| resources.
| bombcar wrote:
| You can turn on lockdown mode on MacOS Ventura and it
| basically disables active compiler JavaScript for all sites
| - you can turn it back on site-by-site but it's interesting
| to see what keeps working.
|
| Benchmark scores go to ass but much of JavaScript I'm
| actually used is just fine.
| kitsunesoba wrote:
| What sites trigger this? Have been using Safari for years and
| haven't encountered such a bug.
| Turing_Machine wrote:
| 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 wrote:
| 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.
| [deleted]
| Amineami114 wrote:
| [dead]
___________________________________________________________________
(page generated 2023-01-07 23:00 UTC)