2068042 - robertsspaceindustries.com - Broken layout, elements not rendered correctly

Status: VERIFIED FIXED

(Core :: CSS Parsing and Computation, defect, P1)

Description

[Calin Tanase]

Environment:
Operating system: Windows 11/10
Firefox version: Firefox Nightly Version 157.0a1

Steps to reproduce:

1. Go to https://robertsspaceindustries.com/en/
2. Dismiss the cookie banner.
3. Observe the page.

Expected Behavior:
The elements are rendered correctly.

Actual Behavior:
The layout is broken, elements are missing or not rendered correctly.

Notes:

• Reproduces regardless of the status of ETP
• Reproduces in firefox-nightly and beta
• Does not reproduce in firefox-release (154), and chrome

Created from https://github.com/webcompat/web-bugs/issues/233231

Comment 1

[Calin Tanase]

Attachment: image.png

Comment 2

[AutoWebCompat]

Attachment: Reproduction script generated by autowebcompat bot

In Firefox Nightly the RSI homepage renders raw CSS source as visible page text (:root { --rsi-mini-bar-height: 2.5rem; }, --orion-navigation-bar-height, --rsi-footer-height), and the navigation bar is blown up into a tall vertical block instead of a single row, pushing the hero image/carousel off screen. Chrome renders the same page correctly: no CSS text is exposed, the nav bar is a normal single-row bar, and the hero content is visible.

Comment 3

[AutoWebCompat]

Attachment: Screenshot generated by autowebcompat bot

Comment 4

[AutoWebCompat]

Root cause analysis generated by autowebcompat bot:

Firefox engine bug in :host selector matching (not UA sniffing). The site ships Swiper's CSS inside an inline document stylesheet, namespaced by its build with a [data-orion-skin] prefix, producing the rule "[data-orion-skin] :host { position: relative; display: block; margin-left: auto; margin-right: auto; z-index: 1 }". The page has body[data-orion-skin]. Per CSS Scoping (https://drafts.csswg.org/css-scoping/#host-selector) :host only matches the shadow host of the shadow tree in which the containing rule appears, so in a document stylesheet it must match nothing, and Chrome treats the rule as inert. Firefox Nightly instead treats a bare :host that appears after a combinator in a complex selector as if it were the universal selector, so "[data-orion-skin] :host" matches every descendant of body and applies display:block to all of them. Two consequences produce the reported breakage. First, display:block overrides the UA stylesheet rule that hides style elements (https://html.spec.whatwg.org/multipage/rendering.html#hidden-elements), so the raw CSS source of the site's injected style blocks is laid out and painted as page text. Second, those now-rendered style blocks sit inside header.o-navigationBar and inside the footer wrapper, and the site's JS measures those containers and writes the result into --orion-navigation-bar-height and --rsi-footer-height; the extra text inflates the measurement to 18.125rem (290px) instead of 4rem (64px) for the nav bar and 76.71875rem for the footer, which pushes the hero/carousel off screen. Narrow divergence: a bare :host in a non-shadow stylesheet, when it is not the first compound of the selector, matches all elements in Firefox and nothing in Chrome.

Evidence:

Live site, 1366x768, default prefs. Firefox: 3 leaked CSS strings in body innerText, nav height 290px, --orion-navigation-bar-height computes to 18.125rem. Chrome: 0 leaked strings, nav height 64px, var 4rem. Identical 17 style elements in both browsers, so no UA sniffing. The leaked text nodes are children of real HTMLStyleElements inside header.o-navigationBar, the platform footer, and a body-level div; their computed display is block in Firefox and none in Chrome, with no inline style attribute and no shadow DOM. Disabling all document stylesheets in Firefox restored display none, so an author rule was responsible. Re-enabling sheets one at a time isolated two inline sheets, and replaying each of that sheet's 488 rules individually into a constructed stylesheet pinpointed exactly one, rule index 462, the Swiper rule with the "[data-orion-skin] :host" selector setting display block. Adopting a probe sheet with that same selector and an outline declaration highlighted 282 of 520 elements in Firefox, including STYLE and SCRIPT, so :host behaved as a universal match. Element.matches with that selector returns false and querySelectorAll returns 0, so the divergence is in style rule matching rather than the selector API. Further probes in Firefox: bare :host matches 0 elements, :host(div) matches 0, "div :host-context(x)" matches 0, but "div :host" matches every descendant of every div. The reduced testcase puts "#wrap :host" with display block in a plain document stylesheet and a style element inside the wrapper. Firefox Nightly: 3 matched elements, leaky style display block, 1 leaked :root string, broken true. Chrome: 0 matched, display none, 0 leaked strings, broken false. Same divergence as the live site.

Comment 5

[AutoWebCompat]

Attachment: Reduced testcase generated by autowebcompat bot

Comment 6

[Donal Meehan [:dmeehan]]

Claude analysis

Bug 2048847 (95301699ebff) added bucketing that marks a selector's subject compound as known-matching so matching can be skipped, but its Component::Host(None) arm deliberately leaves bucket_matches untouched (":host rules are bucketed") — which only holds for shadow-tree host rules. For a bare :host after a combinator in a document stylesheet, the rule lands in the universal bucket as BucketMatches::Subject, so Rule::matches_selector calls iter_past_subject and skips the :host check entirely — making it match every element. That's exactly the site's [data-orion-skin] :host { display: block; ... } rule un-hiding every injected <style>

Comment 7

[BMO Github Automation]

Attachment: [mozilla-firefox/firefox] Bug 2068042 - Fix :host matching regression. r=#style (#354)

Comment 8

[BugBot [:suhaib / :marco]]

:emilio, since you are the author of the regressor, bug 2048847, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/7f3bc24872c6
https://hg.mozilla.org/integration/autoland/rev/eeb045b3a496
Fix :host matching regression. r=dshin

Comment 11

[Goloman Adrian[:agoloman]]

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

Comment 12

[BugBot [:suhaib / :marco]]

The patch landed in nightly and beta is affected.
:emilio, 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-firefox156 to wontfix.

For more information, please visit BugBot documentation.

Comment 13

[Emilio Cobos Álvarez [:emilio]]

Let's back out the regressor from beta instead, Donal is that possible?

Comment 15

[Donal Meehan [:dmeehan]]

(In reply to Emilio Cobos Álvarez [:emilio] from comment #13)

Let's back out the regressor from beta instead, Donal is that possible?

The regressor Bug 2048847 was reverted from Fx156 beta

Comment 16

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

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

Comment 17

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

Upstream PR merged by moz-wptsync-bot

Comment 18

[Raul Bucata]

Verified as FIXED using the RC Build

Tested with:

Browser / Version: Firefox 157.0-candidate build 1
Operating System: Windows 10 PRO x64