1731120 - Rendering difference with Chrome/Safari being seemingly caused by a line box being forced by white-space:pre.

Status: RESOLVED FIXED

(Core :: Layout: Block and Inline, defect)

Description

[Thomas Wisniewski [:twisniewski]]

Attachment: testcase.html

Firefox appears to forced a line box on :after content with white-space:pre, where Chrome and Safari do not (despite content:'' being specified).

This is causing the image gallery arrows on https://m.milliyet.com.tr/ to render differently, as reported and diagnosed at https://webcompat.com/issues/76776 .

See the attached reduced test-case for an example; the bordered square is square on Chrome/Safari but taller than it is wide on Firefox. Dropping the white-space rule resolves the difference.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:dholbert, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: testcase 2: block with empty text node (""), white-space:pre, and tall line-height

This isn't specific to pseudo-elements; it's just a difference in behavior about how empty text nodes are handled.

Here's a testcase where we explicitly insert an empty text node into an element with white-space:pre. Similar to the original testcase, Firefox renders this as tall (honoring the line-height) whereas Chromium does not.

Comment 3

[Daniel Holbert [:dholbert]]

jfkthame, do you know who's correct here?

Comment 4

[Jonathan Kew [:jfkthame]]

According to https://drafts.csswg.org/css-inline/#line-boxes,

Line boxes that contain no text, no preserved white space, no inline boxes with non-zero margins, padding, or borders, and no other in-flow content (such as atomic inlines or ruby annotations), and do not end with a forced line break must be treated as zero-height line boxes for the purposes of determining the positions of any elements inside of them (such as absolutely positioned boxes), and must be treated as not existing for any other purpose (such as collapsing margins).

it looks like we're wrong; an empty text node does not contain any text, and therefore the line box "contain[s] no text" just as it would if the text node were entirely absent.

Comment 5

[Jonathan Kew [:jfkthame]]

white-space: pre-wrap and break-spaces also trigger this, fwiw, as does -moz-pre-space.

Comment 6

[Jonathan Kew [:jfkthame]]

This behavior can be trivially fixed by a change here, as per the question raised in the existing XXX comment. But I'm not sure how many other things this may disrupt.... pushed a try run to see what it looks like.

Comment 7

[Jonathan Kew [:jfkthame]]

No great surprise, this does break a couple of existing tests - for example, it causes an <input type=button value=""> to collapse to zero height. So something a bit more refined will be needed...

(FWIW, it seems a bit odd that <input type=button value=""></input> maintains its line height as if it had text in the label, whereas <button></button> collapses. But that seems to be consistent across browsers, so I guess we shouldn't mess with it.)

Comment 8

[Jonathan Kew [:jfkthame]]

Attachment: Bug 1731120 - Make truly-empty textframes return true for IsEmpty even when WhiteSpaceIsSignificant, unless they're editable or in an <input> element. r=#layout-reviewers

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/5500054be8d6
Make truly-empty textframes return true for IsEmpty even when WhiteSpaceIsSignificant, unless they're editable or in an <input> element. r=emilio

Comment 10

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/31179 for changes under testing/web-platform/tests

Comment 11

[Iulian Moraru]

Backed out for causing android 4.1 shippable build bustages.

Push with failures

Failure log

Backout link

Comment 12

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR was closed without merging

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/49f06640fdee
Make truly-empty textframes return true for IsEmpty even when WhiteSpaceIsSignificant, unless they're editable or in an <input> element. r=emilio

Comment 14

[Marian-Vasile Laza]

https://hg.mozilla.org/mozilla-central/rev/49f06640fdee

Comment 15

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot