2045222 - [Wayland] Opaque region set on toplevel surface despite transparency prefs, breaks transparent browser window (regressed ~20260602)

Status: RESOLVED INVALID

(Core :: Widget: Gtk, defect)

Description

[xusader]

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

Steps to reproduce:

Environment: KDE Plasma 6.6, native Wayland session (about:support
Window Protocol: wayland), WebRender (hardware), AMD RDNA2 iGPU.

1. In about:config, set:
   • toolkit.legacyUserProfileCustomizations.stylesheets = true
   • browser.tabs.allow_transparent_browser = true
   • widget.transparent-windows = true
2. Create chrome/userChrome.css in the profile with a transparent
   window background, e.g.:
   #main-window { background: transparent !important; }
3. Fully quit Firefox (no lingering process) and start it again.

Actual results:

The browser window is rendered fully opaque/dark. The transparent
background does not show through - neither over the wallpaper nor over
other windows.

WAYLAND_DEBUG shows set_opaque_region being called on the TOPLEVEL
wl_surface, covering the content area (offset by the CSD margins):

wl_surface#71.set_opaque_region(wl_region#86)
wl_region#86.add(90, 103, 1535, 977)

This happens even with widget.wayland.opaque-region.enabled=false and
widget.wayland.use-opaque-region=false. The content subsurface's opaque
region is correctly suppressed, but the toplevel region is still set, so
the compositor (KWin) treats the content area as opaque.

Buffers are ARGB (WAYLAND_DEBUG: dmabuf format 875713089 / shm format 0),
so the alpha channel is present - the issue is the opaque region / opaque
background fill on the toplevel, not a missing alpha visual.

Regression range (firefox-nightly-bin):

• Last good: 153.0a1 20260531.212007
• First bad: 153.0a1 20260602.214419
  A mozregression run should pin down the exact changeset.

Possibly related to bug 2013746 (Wayland: WebRender clears content
surface opaque), but this is a distinct, recent regression - chrome
transparency worked through 20260531 and broke with 20260602.

Expected results:

With transparency enabled, the toplevel surface should not be marked
opaque over the content area, and the transparent background should show
through (showing the blurred desktop via the compositor) - exactly as it
did up to and including the 20260531 build.

Comment 1

[Martin Stránský [:stransky] (ni? me)]

Please try to find the exact changeset which broke it.
Thanks.

Comment 2

[xusader]

This is a regression — last good 20260531, first bad 20260602. Possibly related to bug 2013746.

Comment 3

[Martin Stránský [:stransky] (ni? me)]

Bug 2013746 does not have any patch attached and it's open - how it can cause this one?

Comment 4

[xusader]

Sorry for the confusion - I'm not claiming bug 2013746 causes this.
I only linked it as possibly-related symptomatically (opaque content
surface on Wayland). This is a separate regression with a clear range:

• Last good Nightly: 153.0a1 20260531.212007
  (transparent browser-chrome window via userChrome.css works,
  blurred desktop visible behind it)
• First bad: 153.0a1 20260602.214419
  (window rendered opaque; set_opaque_region on the TOPLEVEL surface
  over the content area)

So the trigger is a change that landed between those two builds, not
bug 2013746. I'll run mozregression on that range to find the exact
changeset and follow up.

Comment 5

[xusader]

mozregression has narrowed this down to a single, unambiguous regressor.

Regression window (mozregression, --good 2026-05-31 --bad 2026-06-02):

• Last good: ece5b59d6b987931f6a22e019db434ef1f818807
• First bad: 2b38e442e5d3d3473ad9f8f092f49fa87e3201f4
• Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=ece5b59d6b987931f6a22e019db434ef1f818807&tochange=2b38e442e5d3d3473ad9f8f092f49fa87e3201f4

The first bad changeset is the regressor:

Bug 2042447 - Revert support for translucency with nova enabled
(Sarah Clements, 2026-06-01)

This matches the symptom exactly: with nova enabled, the toplevel surface
now gets an opaque region set despite all transparency prefs being in place
(widget.wayland.opaque-region.enabled=false, widget.wayland.use-opaque-region=false,
mozilla.widget.use-argb-visuals=true, browser.tabs.allow_transparent_browser=true),
resulting in a fully opaque browser window.

Build 153.0a1.20260531.212007 is transparent; 153.0a1.20260602.214419 and later
are opaque.

Re bug 2013746 mentioned earlier: that is only symptomatically related, not the
cause here — it predates this and has no landed patch. The real regressor is the
Bug 2042447 revert above.

Environment: KDE Plasma 6.6 (Wayland), AMD RDNA2 / Mesa, native Wayland backend,
WebRender hardware, custom userChrome.css transparent-window setup.

(I don't have editbugs permissions — could someone set "Regressed by: 2042447"
and the regression keyword? Thanks.)

Comment 6

[xusader]

Note: setting browser.nova.enabled=false (via user.js) does NOT restore
translucency on affected builds — so the revert removes transparency support
beyond just the nova-gated path, or nova is being re-enabled at runtime.

Comment 7

[BugBot [:suhaib / :marco]]

:sclements, since you are the author of the regressor, bug 2042447, could you take a look?

For more information, please visit BugBot documentation.

Comment 8

[Sarah Clements [:sclements] | PTO until Sept 8th]

(In reply to xusader from comment #6)

Note: setting browser.nova.enabled=false (via user.js) does NOT restore
translucency on affected builds — so the revert removes transparency support
beyond just the nova-gated path, or nova is being re-enabled at runtime.

I don't see how bug 2042447 is implicated. If you look at the diff, you can see that I removed one style rule in browser/themes/shared/browser-shared.css gated behind the browser.nova.enabled=true pref and one rule browser/themes/windows/browser.css with browser.nova.enabled=false. The other thing that patch did was to not tie the enabling of browser.nova.enabled to the transparency prefs (for windows and mac), which it flipped on the default branch. Note this change also landed in 153, not 151 as initially reported.

Since Emilio has worked on transparency/vibrancy he might have an idea of what's going on.

Comment 9

[Emilio Cobos Álvarez [:emilio]]

I think comment 0 is wrong. The opaque backdrop is set in body, not #main-window. If I force the <body> to be transparent then stuff works as expected, can you confirm?

Comment 10

[xusader]

Confirmed. Adding

body { background: transparent !important; }

to userChrome.css restores the transparent window on current Nightly
(tested 153.0a1 20260618) — the blurred desktop shows through again,
exactly as before the regression. So Comment 0 was wrong about
#main-window; the opaque backdrop is on body, as you said. Thanks!

One question: with the transparency prefs set, should the body backdrop
be transparent by default, or is the explicit userChrome rule the
intended way going forward? Asking so I know whether to expect this to
keep working or to treat it as a temporary workaround.

Comment 11

[Emilio Cobos Álvarez [:emilio]]

For now userChrome is the way forward. I don't think we want to maintain something like that because what you might want varies. E.g. you might still want the toolbox to be opaque or so.

Thanks for confirming.