1923272 - support.google.com - Description of an article with video does not fit the screen

Status: NEW

(Web Compatibility :: Site Reports, defect, P2)

Description

[Calin Tanase]

Attachment: help page FF vs Chrome.mp4

Environment:
Operating system: OnePlus 6 A6000 (Android 11) / Google Pixel 5 (Android 14)
Firefox version: Nightly 133.0a1-20241007093651

Preconditions:
• Clean profile

Steps to reproduce:

1. Go to https://support.google.com/websearch/search?q=AI
2. Scroll down the page until an article with video is displayed.
3. Observe the layout.

Expected Behavior:
The description/title of the article fits the screen.

Actual Behavior:
The description/title of the article goes off screen.

Notes:

1. Left/right scrolling can be performed on Google Pixel 5 (Android 14) but doesn't seem to hide the description as much as on OnePlus 6 A6000 (Android 11)
2. Screen rec attached
3. Reproducible regardless of the ETP status
4. Reproducible on Firefox Release as well
5. Not reproducible on Chrome
6. Issue found during WebCompat team [Top100] websites testing

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: [initial version of reduced testcase 1; ignore me]

I can't repro on my Pixel 8 (its viewport is wide enough that there's no overflow, I think), but I can repro on desktop in Responsive Design Mode with a screen size of 320x480px.

Here's a rerduced testcase from testcase-reducer (which I further edited to replace width:100% with a hardcoded small width [to emulate a small screen] on the rule for one of the container elements, .scSearchSearch_results_listSearch_resultYoutubepreviewyoutube-preview)

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: reduced tetstcase 1

(editing the testcase a little bit further to add a border around the element. Interestingly, both Firefox and Chrome overshoot the border; we just overshoot by more.)

Comment 3

[Daniel Holbert [:dholbert]]

Ah, so the overflowing side here (in both Chrome and Firefox) comes from white-space: nowrap on the span that's wrapping the November 15, 2023 text, specifically this rule:

.scSearchSearch_results_listSearch_resultYoutubepreviewlabel-container {
    white-space: nowrap;
}

In Chrome, the min-content contribution for that element will be the width of that full date. If I remove that, then Chrome doesn't overflow beyond the black border anymore.

In Firefox, something similar happens, but the interesting differnece is that Chrome sees a linebreak opportunity between the view-count and the date, whereas we do not, so we end up thinking the whole 335K views November 15, 2023 string is unbreakable, which gives us a much larger min-content intrinsic-width contribution.

Comment 4

[Daniel Holbert [:dholbert]]

Attachment: reduced testcase 2

Here's a substantially-more-reduced testcase, comparing the same markup with/without an orange inline-block inside of a white-space:nowrap span (and with vs. without text before that inline-block).

Firefox renders this testcase with no linebreaks in any of the three parts (honoring white-space:nowrap).

Chromium and WebKit both render the first part with a linebreak before the orange square, but no linebreak in the second or third parts of this testcase.

The first part of this testcase is analogous to the actual site here, so that's why the site "works" in Chrome and WebKit, but I'm not sure their behavior is correct.

Comment 5

[Daniel Holbert [:dholbert]]

Attachment: reduced testcase 3 (using replaced element instead of inline-block)

This version is the same as the previous, except now I've swapped out the orange inline-block elements and replaced them with teal <canvas> elements.

Browsers render this exactly the same as the previous testcase - Chromium/WebKit linebreak in the first section but not the others, and Firefox doesn't linebreak at all.

Comment 6

[Daniel Holbert [:dholbert]]

jfkthame, do you know why other browsers find a linebreaking opportunity in the first section of reduced testcase 2 and 3 here?Is there any good reason to do that?

nowrap seems to be defined here:

nowrap
Inline-level content does not break across lines; content that does not fit within the block container overflows it.

https://drafts.csswg.org/css-text-4/#valdef-text-wrap-mode-nowrap doesn't
...and doesn't have any special exception for atomic inlines at the edges of elements.

The "Line Breaking Details" section does say the following:

For Web-compatibility there is a soft wrap opportunity before and after each replaced element or other atomic inline, even when adjacent to a character that would normally suppress them, including U+00A0 NO-BREAK SPACE.

https://drafts.csswg.org/css-text-4/#line-break-details

However, this doesn't explain why Chromium and WebKit are only breaking when the atomic inline is at the edge of a span (only in the first part of the testcase but not in the second).

Comment 7

[Daniel Holbert [:dholbert]]

Aha, maybe this has to do with the combination of the "soft wrap opportunity" bullet-point that I quoted above, combined with this bullet-point that comes a bit later in the same section:

• For soft wrap opportunities before the first or after the last character of a box, the break occurs immediately before/after the box (at its margin edge) rather than breaking the box between its content edge and the content.

Putting those two bullet-points together, I suspect Chromium/WebKit are doing something like this:
(A) They consider there to be a soft wrap opportunity before/after the atomic inline (the inline-block or canvas in my testcases).
(B) If the atomic inline is at the start of the span, then the soft-wrap-opportunity that comes before it is considered to generate a break outside of the span.
(C) When evaluating linebreaks, we suppress breaks inside of the span (honoring white-space:nowrap), but the one that got created outside of the span is not suppressed, because it's outside.

This ends up feeling a bit odd, but maybe not too terrible...

Comment 8

[Daniel Holbert [:dholbert]]

I filed bug 1927524 as a platform bug here.

Canceling needinfo about whether-other-browsers'-behavior-makes-sense because I think I sorted it out in comment 7 (and re-expressed the rationale in bug 1927524).

Comment 9

[Jonathan Kew [:jfkthame]]

Interestingly, it looks like webkit's behavior has changed fairly recently: in my normal Safari here (Version 17.6), it does not line-break in the first section of your testcases. But in Safari Tech Preview (Release 201 (Safari 18.0, WebKit 19620.1.2)), I do see that line-break happening.

I think your description in comment 7 must be what they're doing, though I'm not convinced it is justified by the spec... the soft wrap opportunity created "for web-compatibility" is still inside the scope of white-space: nowrap and therefore it seems like it shouldn't be used. But it's an edge case (quite literally!) that may be arguable various ways...

[edit, after re-reading again, I think your description in bug 1927524 makes sense, and that wrap opportunity should be usable]