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

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.

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.

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.

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)

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

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

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.

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