Closed Bug 1657437 Opened 4 years ago Closed 4 years ago

Lone CR causes previous whitespace to get collapsed.

Categories

(Core :: Layout: Text and Fonts, defect)

78 Branch
defect

Tracking

()

RESOLVED FIXED
81 Branch
Tracking Status
firefox81 --- fixed

People

(Reporter: krinkle, Assigned: emilio)

Details

(Keywords: parity-chrome, Whiteboard: [platform-rel-Wikipedia], [wptsync upstream])

Attachments

(5 files)

Attached image capture-firefox.png

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Firefox/78.0

Steps to reproduce:

  1. HTML element with a title attribute value containing (carriage return).
  2. 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.

Attached image capture-chrome.png
Whiteboard: [platform-rel-Wikipedia]
Component: Untriaged → CSS Parsing and Computation
Product: Firefox → Core

I can't see the issue on my local Linux box on nightly.

Severity: -- → S3
Component: CSS Parsing and Computation → Layout: Text and Fonts
Attached file Bug 1657437.html

I can reproduce Nightly81.0a1 Ubunto20.04 and Windows10 as well.

STR:

  1. open attached html

Actual results:

ww

Expected results:

w w
Keywords: parity-chrome
Attached file Another test-case

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.

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

Summary: Line break and surrounding whitespace stripped from CSS pseudo-element content → Lone CR causes previous whitespace to get collapsed.

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.

Assignee: nobody → emilio
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
Whiteboard: [platform-rel-Wikipedia] → [platform-rel-Wikipedia], [wptsync upstream]
Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → 81 Branch
Upstream PR merged by moz-wptsync-bot
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: