News for hackers. Stuff that matters.
Re:The Safari bug that never was (2022) by ojintoad on Saturday January 07, 2023 @02:16PM (#34291544)
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

Re:The Safari bug that never was (2022) by JonathonW on Saturday January 07, 2023 @03:11PM (#34292164)
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.