Bug 247481 – white-space: break-spaces seems to collapse or hang spaces after element boundaries

• Component: Layout and Rendering
• Status: RESOLVED CONFIGURATION CHANGED

[Andreu Botella]

Created attachment 463398 [details]
Test case for this bug

The `white-space: break-spaces` CSS property should not hang or collapse spaces, and should only allow breaking after spaces rather than before them. But it seems like in Webkit, in some cases an element boundary before a space can collapse or hang the space, even when that element does not change the `white-space` property with respect to its parent.

In the attachment test, notice that there is no space at the start of the second line before "BB", which means either the space after "AAAA" overflowed, or it collapsed or hanged. However, "C " is allowed to overflow and doesn't here, so the space does not seem to be considered for line-breaking purposes, when it should.

This is an issue considered for the "web compat" part of Interop 2023 (https://github.com/web-platform-tests/interop/issues/187), which was initially reported as a bug in Chromium before I noticed Webkit also has a related bug.

[alan]

(In reply to Andreu Botella from comment #0)
> Created attachment 463398 [details]
> Test case for this bug
> 
> The `white-space: break-spaces` CSS property should not hang or collapse
> spaces, and should only allow breaking after spaces rather than before them.
> But it seems like in Webkit, in some cases an element boundary before a
> space can collapse or hang the space, even when that element does not change
> the `white-space` property with respect to its parent.
> 
> In the attachment test, notice that there is no space at the start of the
> second line before "BB", which means either the space after "AAAA"
> overflowed, or it collapsed or hanged. However, "C " is allowed to overflow
> and doesn't here, so the space does not seem to be considered for
> line-breaking purposes, when it should.
> 
> This is an issue considered for the "web compat" part of Interop 2023
> (https://github.com/web-platform-tests/interop/issues/187), which was
> initially reported as a bug in Chromium before I noticed Webkit also has a
> related bug.
Thanks for filing this issue. I looked at the compat bug (https://codepen.io/kizu/pen/mdMEOvw) and it renders fine on trunk WebKit (see attached screenshot). The attached test case renders the same in all browsers (see attached screenshot) so I am a bit puzzled of what the compat issue here is.
first line: "AAAA "
second line: "BB "
third line: "C D" 
(in both cases)

first line: we break _at_ the first soft wrap opportunity which is _after_ the preserved white space and yes, it overflows the block container's content box.
second line: we see "BB C" fit the line and proceed to the next "character" and find the white space.
Now since there's no soft wrap opportunity between "C" and " ", we either 
1. proceed further and include the trailing white space and produce a line of "BB C " or 
2. revert to the last wrap opportunity (_after_ the first white space) and produce a line of "BB ".
We choose the latter and break _after_ the preserved white space (no overflow here).
third line: fits as is.

[alan]

Created attachment 463402 [details]
web compat screenshot

[alan]

Created attachment 463403 [details]
test case screenshot

[Andreu Botella]

Epiphany (both stable and TP) does show a difference. I'm looking into whether this is something that changed at some point in Webkit and Epiphany and Safari are using different versions, or whether this is something that changes depending on the port.

[Andreu Botella]

Created attachment 463404 [details]
test case as rendered in Epiphany

[alan]

ok, so either modern line layout (IFC) is not turned on or it's a recent trunk progression.

[Radar WebKit Bug Importer]

<rdar://problem/102233630>

[Ahmad Saleem]

Attached test case and also 'https://codepen.io/kizu/pen/mdMEOvw' are rendering same in Chrome Canary 128, Firefox Nightly and Safari 17.6 Beta.

@Alan - can we close this as 'RESOLVED CONFIGURATION CHANGED' because of IFC Progression?

[Andreu Botella]

I just checked, and it seems like Epiphany 46.0 now renders the same as Firefox and Chromium, so it seems like the bug can indeed be closed.

[alan]

Thank you, Andreu for confirming!

(IFC progression)