Lone CR causes previous whitespace to get collapsed.
Categories
(Core :: Layout: Text and Fonts, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox81 | --- | fixed |
People
(Reporter: krinkle, Assigned: emilio)
Details
(Keywords: parity-chrome, Whiteboard: [platform-rel-Wikipedia], [wptsync upstream])
Attachments
(5 files)
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Firefox/78.0
Steps to reproduce:
- HTML element with a title attribute value containing (carriage return).
- Create a
:before
or:after
pseudo-element where the content comes from that attribute.
Actual results:
The line break, and other whitespace surrounding the line break, are eaten by Firefox. It seems there is also no way to make them come back, e.g. through white-space: pre-wrap or some such.
Expected results:
Based on the semantics of whitespace in HTML, I would expect line breaks to render as a regular space and for sequences of whitespace of any kind to be collapsed into a single space. I would also expect that white-space: pre-wrap
allow line breaks to render as actual line breaks.
Test case:
https://codepen.io/Krinkle/pen/bGpbjBa?editors=1000
The bug appears specific to Firefox.
The space does appear in Safari and Chrome.
Reporter | ||
Comment 1•4 years ago
|
||
Reporter | ||
Updated•4 years ago
|
Updated•4 years ago
|
Comment 2•4 years ago
|
||
I can't see the issue on my local Linux box on nightly.
Comment 3•4 years ago
|
||
I can reproduce Nightly81.0a1 Ubunto20.04 and Windows10 as well.
STR:
- open attached html
Actual results:
ww
Expected results:
w w
Updated•4 years ago
|
Assignee | ||
Comment 4•4 years ago
|
||
Yeah, this doesn't seem to be specific to generated content at all, this is just about how we handle windows-style carriage-returns (as opposed to normal line-feeds (

).
I don't see anything in https://drafts.csswg.org/css-text-3/#white-space-rules that makes our behavior or Chrome's incorrect, fwiw, I guess it depends on whether you treat or not CR as a segment break, which is not defined by CSS... but I could be wrong of course.
Assignee | ||
Comment 5•4 years ago
|
||
Removing CR from https://searchfox.org/mozilla-central/rev/b4f3ce16c5099cf068fb023341959a0457adec9e/layout/generic/nsTextFrameUtils.cpp#50 helps here, though I wonder if we should treat them as a space or not... Let's see what our tests think...
Assignee | ||
Comment 6•4 years ago
|
||
That prevents preceding whitespace from getting collapsed.
When there's a single lone CR (so a\rb
) our behavior here diverges
from Chrome's but matches Safari's. We treat it as ZWSP.
That matches the initial resolution of 1, but then there have been
various doing and undoings of that resolution, so it's not totally clear
to me what the correct behavior per spec should be. I think "treat it as
other control character"? But I haven't dug into what that implies, so
for now I've just kept behavior there as-is.
Updated•4 years ago
|
Pushed by ealvarez@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/b579c12907dc Don't treat lone CRs as segment breaks. r=jfkthame
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/24930 for changes under testing/web-platform/tests
Comment 9•4 years ago
|
||
bugherder |
Upstream PR merged by moz-wptsync-bot
Description
•