1934547 - "-webkit-line-clamp" prevents painting of absolutely positioned children that are in the line-clamped range (e.g. `::after` pseudo-element), even if their absolute position would put them in view

Status: VERIFIED FIXED

(Core :: Layout, defect)

Description

[phpcoder2022]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:133.0) Gecko/20100101 Firefox/133.0

Steps to reproduce:

1. Visit the pen Firefox -webkit-box bug
2. Activate any from :hover, :focus, :active states of every card links
3. See darkening results

Actual results:

The second card doesn't darken by :hover, :focus, :active of its link.
The first card works fine.

Expected results:

All cards work fine.

Notes:

If replace .card__link + *::after to .card__link + *::before, all cards will work fine.
Example in the this pen.

Comment 1

[Daniel Holbert [:dholbert]]

Chromium (with experimental web-platform-features enabled) works like Firefox as far as I can tell.
WebKit matches the author's expectation (the second card darkens slightly when hovered).

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: reduced testcase 1

Here's a somewhat reduced testcase.

Firefox and Chromium (with experimental web-platform-features enabled) render this with one blue-gradient box. WebKit renders it with two such boxes.

Comment 3

[Daniel Holbert [:dholbert]]

Attachment: reduced testcase 2

Ah, so what's happening here (i.e. why this works as-the-reporter-expects in WebKit vs. doesn't in Firefox/Chromium) has to do with how -webkit-line-clamp is implemented.

In Firefox and Chrome (with experimental web-platform-features enabled) , content after the line-clamped line doesn't render at all.
In WebKit, it does render, and WebKit just ellipsizes and does not actually clamp from a rendering perspective -- they're reliant on the author also providing overflow:hidden to actually clip the clamped lines (but that's not-great because e.g. the lines might have some overdraw that ends up being visible).

Here's a testcase where I've taken away overflow:hidden and you can see that Firefox/Chrome do still clamp the lines (and the ::after-generated content after the lines), whereas WebKit does not.

Comment 4

[Daniel Holbert [:dholbert]]

(In the reporter's testcase, the ::after-generated thing is a partially-transparent overlay div which does the darkening effect. In Firefox and Chrome, webkit-line-clamp clamps that element away, because it's after the clamping point.

Firefox and Chrome (with experimental web-platform-features enabled) are closer to the spec text here:
https://drafts.csswg.org/css-overflow-4/#propdef-line-clamp
Quoting that spec text: "It allows limiting the contents of a block container to the specified number of lines; remaining content is fragmented away and neither rendered nor measured".

This is what Chrome/Firefox do, basically.
Whereas, I think WebKit does render the clamped content (as in e.g. reduced testcase 2), hence the reason why web developers often have to include for overfow:hidden or similar to get this clamping to work there.

This testcase is relying on the browser to render the content, but that goes against the spec for how the standardized version of this feature is supposed to work.

So, this is invalid; the testcase is relying on a WebKit bug to try to achieve the desired effect.

Comment 5

[phpcoder2022]

Hello.

Thank you for your response to my request.
I tested in Firefox and Chromium.
Chromium behaves differently from Firefox.
I remade example and recorded screencasts to confirm this.
Please reopen the ticket.

Comment 6

[phpcoder2022]

I added screencast about work in chrome (not chromium) also to screencasts folder

Comment 7

[Daniel Holbert [:dholbert]]

Aha, I forgot that the Chrome version that I was testing wasn't the "stock" version -- I was testing Chrome 133 dev with "Experimental Web Platform Features" enabled (at chrome://flags).

That activates Chrome's updated implementation of -webkit-line-clamp which is closer to the spec and which matches Firefox on the original testcase, testcase 5, and all of the reduced testcases that I attached here.

So: you're correct that Chrome's currently-shipping behavior is different from Firefox, but it doesn't match the spec and they're in the process of moving away from it (to align with the spec), so this remains not-a-bug-in-Firefox and you probably don't want to start depending on the Chrome/WebKit behavior since they're planning to align with us (per spec).

Comment 8

[Daniel Holbert [:dholbert]]

Attachment: screencast showing that Chrome changes behavior (to match Firefox) if you enable their "Experimental Web Platform features" flag

Here's a screencast to demonstrate Chrome matching Safari by default but matching Firefox when I enable their "Experimental Web Platform features" setting. (They're in the process of modernizing their line-clamp implementation, moving away from the legacy behavior.)

Comment 9

[Daniel Holbert [:dholbert]]

(also, the fact that -webkit-box makes a difference here is just as a legacy "switch" that's required in order to make -webkit-line-clamp actually do anything. It's not great that that switch exists, but we're stuck with it due to webcompat constraints, i.e. existing content would break if browsers removed that restriction and broadened the applicability of -webkit-line-clamp. The unprefixed version of line-clamp won't have that restriction, though.)

Comment 10

[phpcoder2022]

Ok. Thanks for the detailed explanation. I'll keep that in mind that need the checking with flag too

Comment 11

[Daniel Holbert [:dholbert]]

Thanks!

Two additional notes:
(1) We got one other report recently that turned out to be this exact same issue: bug 1936267, affecting a button on certain line-clamped linkedin pages.

(2) Historical reference -- our current behavior of declining-to-paint-the-line-clamped-child here is from bug 1791226, particularly this last patch "Don't paint line-clamped lines": https://hg.mozilla.org/mozilla-central/rev/cf9f54eef334 -- so let's mark this as "regressed-by" that bug, even though this new behavior is intended. Nightly builds from before that commit (e.g. Nightly 2024-10-20) match the reporter's expectation here, because those builds were implementing the legacy model/spec-text.

Comment 12

[Daniel Holbert [:dholbert]]

emilio: we've now got 3 distinct bugs with a common pattern: an abspos element at the end of a -webkit-line-clamp'ed section that used to render but no longer does. (Those bugs being: this bug here, bug 1936267 for linkedin.com, bug 1934811 for afisha.ru. In the latter two cases, it's not just a cosmetic issue, since the missing element is a "Show more" button which would remove the clamping; and so there's no way for users to toggle the "stop clamping and show me the whole paragraph" action because the button that would do that is itself not rendered due to the clamping.)

I wonder if it's worth revisiting the approach (and the associated spec-change-proposal) that we landed in https://hg.mozilla.org/mozilla-central/rev/cf9f54eef334 (which Chrome also has implemented behind a flag), and perhaps exempting abspos content (and their placeholder frames) and allowing them to render?

Comment 13

[Daniel Holbert [:dholbert]]

--> reopening since this is causing some webcompat pain and we might need to change course and see about changing the spec (though maybe if Chrome ships the same behavior that's currently behind a flag, that'll be enough of a nudge to get affected sites to notice the problem and update, e.g. by moving these abspos elements to be at the start of the line-clamped element's DOM rather than at the end)

Comment 14

[BugBot [:suhaib / :marco]]

Set release status flags based on info from the regressing bug 1791226

Comment 15

[Emilio Cobos Álvarez [:emilio]]

Attachment: Bug 1934547 - Disable skipping line-clamped lines by default for now. r=dholbert!,#layout!

The right thing to do long term is to probably allow abspos boxes and so
on, but let's revert to our previous behavior for now adding a pref.

Comment 16

[Daniel Holbert [:dholbert]]

Attachment: testcase 3: possible makings of a WPT

Comment 17

[Daniel Holbert [:dholbert]]

Attachment: testcase 3: possible makings of a WPT

(reposting testcase 3 with copypasta title fixed up)

Comment 18

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #7)

Aha, I forgot that the Chrome version that I was testing wasn't the "stock" version -- I was testing Chrome 133 dev with "Experimental Web Platform Features" enabled (at chrome://flags).

That activates Chrome's updated implementation of -webkit-line-clamp which is closer to the spec and which matches Firefox on the original testcase, testcase 5, and all of the reduced testcases that I attached here.

BTW, I reached out to a contact on the Chrome team to alert them to this issue so they don't inadvertently graduate their updated implementation past the "Experimental Web Platform Features" feature-flag without realizing that they'll hit these sorts of issues too.

Comment 19

[Emilio Cobos Álvarez [:emilio]]

Sorry for the lack of context for the patch, I forgot to press enter (or mid-aired or something)... Had written:

Yeah, agreed. Don't have much time to look into it right now tho (technically on PTO already), so let's disable the behavior for now.

Comment 20

[Daniel Holbert [:dholbert]]

No worries, and thanks for the quick action!

I'm happy to morph the attached testcase into a WPT if you don't have time to do it (particularly given that you're on PTO already), but I'll wait to hear from you first so as not to duplicate work in case you're already doing that. :)

Comment 21

[Emilio Cobos Álvarez [:emilio]]

I did that :)

Comment 22

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/7e2ae0e42af3
Disable skipping line-clamped lines by default for now. r=dholbert,layout-reviewers

Comment 23

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/49667 for changes under testing/web-platform/tests

Comment 24

[amarc]

https://hg.mozilla.org/mozilla-central/rev/7e2ae0e42af3

Comment 25

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot

Comment 26

[Daniel Holbert [:dholbert]]

Attachment: Bug 1934547 - Disable skipping line-clamped lines by default for now. r=dholbert!,#layout!

The right thing to do long term is to probably allow abspos boxes and so
on, but let's revert to our previous behavior for now adding a pref.

Original Revision: https://phabricator.services.mozilla.com/D231974

Comment 27

[Daniel Holbert [:dholbert]]

[Creating beta-uplift request on emilio's behalf since he's on PTO.]

Comment 28

[Daniel Holbert [:dholbert]]

I verified that this is fixed in today's Nightly (launched with mozregression --launch 2024-12-13).

By default, I get expected results (matching stock Chrome [no experimental features enabled]) on the attached & linked testcases here.
If I enable about:config pref layout.css.webkit-line-clamp.skip-paint, it brings back the actual-results described above (as expected).
--> VERIFIED FIXED in 135

Comment 29

[Phabricator Automation]

beta Uplift Approval Request

• User impact if declined: Missing buttons/content on some sites (including LinkedIn)
• Code covered by automated testing: yes
• Fix verified in Nightly: yes
• Needs manual QE test: yes
• Steps to reproduce for manual QE testing: Load https://bug1934547.bmoattachments.org/attachment.cgi?id=9442830 , check for "can you see me" text.
• Risk associated with taking this patch: Low
• Explanation of risk level: This is essentially just putting a recently-introduced behavior (which we're the only ones to ship so far) behind an off-by-default about:config pref.
• String changes made/needed: None
• Is Android affected?: yes

Comment 30

[Daniel Holbert [:dholbert]]

(In reply to Phabricator Automation from comment #29)

• Steps to reproduce for manual QE testing: Load https://bug1934547.bmoattachments.org/attachment.cgi?id=9442830 , check for "can you see me" text.

(To clarify: actual-results [in buggy builds] are that the "can you see me" text is missing, and expected-results [in patched builds] are that the "can you see me" text should be visible)

Comment 31

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-beta/rev/94942ade789a

Comment 33

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #12)

I wonder if it's worth revisiting the approach ... perhaps exempting abspos content (and their placeholder frames) and allowing them to render?

FWIW, bug 1937466 (which I just duped here) appears to have a case where abspos stuff wasn't involved at all -- over there, the user was expecting "regular" line-clamped lines of text to still be painted and visible-if-scrolled-into-view. The user's screenshot appears to show an overflow:auto line-clamped element whose clamped lines can be viewed by scrolling (but aren't painted in Firefox 133, for reasons discussed above). The expected-results there are a bit odd as a usecase for line-clamping, since one of the words will be truncated with the ellipsis, while the words-that-follow would be readable... I'm not sure if that was accidental on the part of the website's designer there.

Anyway: just mentioning this as an additional data-point for "weird ways that actual content uses this feature in-the-wild", if/when we reconsider the spec change in question here, as part of getting the Firefox-133-behavior re-enabled.

Comment 34

[Ardelean Oana, Desktop Test Engineering [:oardelean]]

Reproducible on a 2024-12-02 Nightly build on Windows 10.
Verified as fixed on Firefox Nightly 135.0a1 and Firefox 134.0 on Windows 10, Ubuntu 22, macOS 14.