Closed Bug 1731120 Opened 3 years ago Closed 3 years ago

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


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




95 Branch
Webcompat Priority ?
Tracking Status
firefox95 --- fixed


(Reporter: twisniewski, Assigned: jfkthame)


(Regressed 1 open bug, )



(3 files)

Attached file 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 to render differently, as reported and diagnosed at .

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.

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

For more information, please visit auto_nag documentation.

Flags: needinfo?(dholbert)

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.

jfkthame, do you know who's correct here?

Severity: -- → S3
Component: Layout → Layout: Block and Inline
Flags: needinfo?(dholbert) → needinfo?(jfkthame)

According to,

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.

Flags: needinfo?(jfkthame)

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

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.

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

Assignee: nobody → jfkthame
Pushed by
Make truly-empty textframes return true for IsEmpty even when WhiteSpaceIsSignificant, unless they're editable or in an <input> element. r=emilio
Created web-platform-tests PR for changes under testing/web-platform/tests

Backed out for causing android 4.1 shippable build bustages.

Push with failures

Failure log

Backout link

Flags: needinfo?(jfkthame)
Upstream PR was closed without merging
Pushed by
Make truly-empty textframes return true for IsEmpty even when WhiteSpaceIsSignificant, unless they're editable or in an <input> element. r=emilio
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → 95 Branch
Upstream PR merged by moz-wptsync-bot
Flags: needinfo?(jfkthame)
Duplicate of this bug: 1680706
Regressions: 1901624
You need to log in before you can comment on or make changes to this bug.