1964575 - Failure to correctly invalidate/repaint in response to a complex :not() selector [was: white-space-collapse breaks white-space: nowrap;]

Status: RESOLVED FIXED

(Core :: CSS Parsing and Computation, defect)

Description

[reports]

Steps to reproduce:

When Mozilla added the new text-wrap-mode and white-space-collapse someone screwed up and destroyed white-space: nowrap;.

Now white-space: nowrap; is rendered as text-wrap-mode: nowrap; + white-space-collapse: collapse; which is !== to white-space: nowrap; .

In a narrow column menu of 185px there are menus (<div><a><span></span><span></span></a></div>). For menus with longer text they are set to display an ellipsis. Then when a:hover span {white-space: nowrap;} is applied the wrapping is disabled (and the second a span is hidden) in order to show more of the text. However now no changes are made at all due to this bug.

Some quick testing shows that in order to get:

white-space: nowrap;

I now have to use:

white-space: nowrap;
white-space-collapse: unset !important;

If this bug gets attention I'll be happy to create a test case.

Comment 1

[Jonathan Kew [:jfkthame]]

(In reply to reports from comment #0)

If this bug gets attention I'll be happy to create a test case.

A test case would be helpful, thank you.

Checking the CSS Text spec, it's unclear to me whether there's a bug here, but seeing a complete example may help to clarify things.

Note that in the spec, nowrap is not listed as one of the "special keywords" that maps to a combination of text-wrap-mode and white-space-collapse, so my understanding is that white-space: nowrap is only specifying a value for the text-wrap-mode property. And the spec then notes that "unless otherwise specified, any omitted longhand is set to its initial value", so I'd expect white-space-collapse to be set to collapse (its initial value).

To use white-space to make text neither wrap nor collapse, the appropriate value would be pre, which the spec lists as a "special keyword" that sets both white-space-collapse: preserve and text-wrap-mode: nowrap.

Comment 2

[reports]

Attachment: Test focus/hover in 115 ESR works versus 128 ESR or 138 broken.

Hi Jonathan,

So this bug report seems to be evolving to also include a CSS selector bug.

I'm attaching the file "1964575-1.xhtml" which works fine in Firefox 115 ESR but not 128 ESR. I also confirmed it still does not work in the superfluous 138 release.

The test has a sidebar navigation for my Mail Module. The correct behavior is when you focus or hover an anchor with longer text that it will be revealed. However now in Firefox 128 ESR / 138 it does nothing! So in the test case I started adding background-colors to test what does and does not work. When I use JavaScript's querySelectorAll the selector works fine for the :not() however when applied on the page it breaks. All of the span elements turned blue should ALSO become fuchsia when focused or hovered.

Works:
1:
[id^="mail"] section > nav div:not([id^="mail"] section > nav > hr:last-of-type ~ div) > :is(a) span {background-color: #00f;}

Does not work:
1:
[id^="mail"] section > nav div:not(hr:last-of-type ~ div) > :is(a:focus, a:hover) span {background-color: #f0f !important;}

2:
[id^="mail"] section > nav div:not(hr:last-of-type ~ div) > :is(a:focus, a:hover) span {background-color: #f0f !important;}

3:
[id^="mail"] section > nav div:not([id^="mail"] section > nav > hr:last-of-type ~ div) > a:focus span,
[id^="mail"] section > nav div:not([id^="mail"] section > nav > hr:last-of-type ~ div) > a:hover span
{background-color: #f0f !important;}

I'm already under several compounded layers of excess time having to deal with projects let alone browser bugs. So I can't throw several more hours to pin-point the exact issues with the CSS :not() not working here. I hope this clarifies enough to get things moving forward at least.

Comment 3

[Jonathan Kew [:jfkthame]]

So the most readily-observable issue in the testcase is that the second block of blue items don't turn magenta when hovered, right?

A specific example of a selector that used to match on hover, but no longer seems to work, is:

[id^="_mail_"] section > nav div:not([id^="_mail_"] section > nav > hr:last-of-type ~ div) > a:hover span {
  width: var(--mail_nav-width);
  background-color: #f0f !important;
}

Actually, if I hover over one of the relevant items and then hit Cmd-+ to zoom the page, the item does change to magenta. I think it's not that the selector fails to match, but that the rendering doesn't get invalidated properly and so the changed style doesn't appear to take effect (until the zoom operation causes a full reflow).

This seems to have regressed in Firefox 121 here: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=de086751acb845c252c37aab95a7e6b265df39a6&tochange=cfb42711da4589f5ede0032644a6d577d66aa468

Within that range, I suspect bug 1874042 may be the culprit.

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

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

Comment 5

[David Shin[:dshin]]

Attachment: Example without hover

Comment 6

[David Shin[:dshin]]

Attachment: Minimum Reproducible Case

Comment 7

[David Shin[:dshin]]

Attachment: Bug 1964575: Take negation into account when coercing unknown matching result to matched. r=#style

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/a9b4912f6ddd
Take negation into account when coercing unknown matching result to matched. r=firefox-style-system-reviewers,emilio

Comment 9

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

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

Comment 10

[Cristina Horotan [:chorotan]]

https://hg.mozilla.org/mozilla-central/rev/a9b4912f6ddd

Comment 11

[BugBot [:suhaib / :marco/ :calixte]]

The patch landed in nightly and beta is affected.
:dshin, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
  • See https://wiki.mozilla.org/Release_Management/Requesting_an_Uplift for documentation on how to request an uplift.
• If no, please set status-firefox139 to wontfix.

For more information, please visit BugBot documentation.

Comment 12

[David Shin[:dshin]]

I think it's fine to let it ride the train to 140.

Comment 13

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

Upstream PR merged by moz-wptsync-bot

Comment 14

[reports]

David, thank you for taking the time to fix the bug! I downloaded Firefox Nightly and confirmed that the menu navigation is now working correctly for all anchors. It looks like 140 is the next ESR so I'm grateful that it'll be in the next business-friendly release. Thanks!