1577028 - Trailing newline "\n" character(s) after the body are pulled into the final text node and occupy layout space

Status: RESOLVED INVALID

(Core :: Layout, defect, P3)

Description

[Daniel Holbert [:dholbert]]

STR:
(1) Load testcase
(2a) Select-all
...or:
(2b) In layout debugger, dump the frame tree.

ACTUAL RESULTS:
For 2a: The select-all-highlighting shows a bit of extra highlighted area to the right of the character -- it looks like a whitespace character.
For 2b: The framedump shows something like this:

Text(0)"X\n"@...  {0,0,690,1140} vis-overflow={0,0,990,1140} ...

Notably, there's a bogus "\n" character shown as part of the text-run, and we think there's some visual overflow (690 width in the frame rect vs. 990 width in the visual-overflow rect).

EXPECTED RESULTS:
For 2a: The select-all highlighting should tightly wrap the X character.
For 2b: There shouldn't be a weird stray \n character, and the framedump shouldn't show any visual overflow beyond the frame rect.
[EDIT: Actually maybe it's correct that the \n character shows up as part of the text node -- but it's still quite odd that it creates 1 horizontal space worth of visual overflow...]

Morgan discovered this issue while working on backplates (which is dependent on the visual overflow area)

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: reference case 1a (added a `span` wrapper)

This reference case (which just has an added span wrapper, tightly wrapping the X) gives EXPECTED RESULTS.

Comment 3

[Daniel Holbert [:dholbert]]

Attachment: reference case 2 (removed final newline character after </body>)

If I adjust the testcase to remove the its final closing newline character (so that e.g. hg would warn me about no trailing newline in the file), then I get EXPECTED RESULTS as well.

Comment 4

[Daniel Holbert [:dholbert]]

Chrome 78 (dev) and Safari 12.1 give EXPECTED RESULTS on testcase 1 (for the "select-all" method of testing, 2b) -- they don't highlight any extra space.

Edge 18 (EdgeHTML) gives ACTUAL RESULTS (matching us).

Comment 5

[Jonathan Kew [:jfkthame]]

Doesn't this look like it might be more of a parsing/DOM-construction issue than layout? With your testcase, document.body.firstChild appears to be a text node that contains "X\n". Given this, I think it's expected that it appears as trailing whitespace (after segment break transformation) on the line, and can be highlighted as such. What does seem surprising to me that the newline from after the closing </body> tag is ending up within the body element's text child.

Ah, https://html.spec.whatwg.org/#parsing-main-afterbody says:

When the user agent is to apply the rules for the "after body" insertion mode, the user agent must handle the token as follows:

A character token that is one of U+0009 CHARACTER TABULATION, U+000A LINE FEED (LF), U+000C FORM FEED (FF), U+000D CARRIAGE RETURN (CR), or U+0020 SPACE

• Process the token using the rules for the "in body" insertion mode.

which does sound (without having worked through all the rules that may be involved) like it could append newlines from after the closing tag to the content of the body. So this behavior may be per spec?

Comment 6

[Jonathan Kew [:jfkthame]]

Daniel, do you think there's actually a bug here we should try to fix, or does comment 5 provide sufficient explanation?

Comment 7

[Daniel Holbert [:dholbert]]

While this behavior is a bit counterintuitive, I think you're right that it matches the spec chunk quoted in comment 5, and it's not actually a bug.

Comment 8

[Morgan Reschenberg [:morgan]]

Turns out this is also an issue when we create accessible names for text leaves (ie. data:text/html,hello<br>world). In that test case, the last text leaf will have a name of "world " with a trailing space. Nothing too horrible, just noting here in case its relevant for someone else in the future :)