2006361 - GTK4 Linux builds lack client-side decorations, breaking GTK window controls and theming on Wayland

Status: UNCONFIRMED

(Core :: Widget: Gtk, defect, P3)

Description

[DFM]

Attachment: Bildschirmfoto vom 2025-12-16 16-26-02.png

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

Steps to reproduce:

On Linux (GNOME, Wayland), recent Firefox builds using GTK4 no longer expose or support client-side decorations (CSD) in a way that allows GTK themes to provide window controls.

In my current Firefox-derived build (LibreWolf, Debian-based), the preference

widget.gtk.client-side-decoration.enabled

does not exist at all in about:config, indicating that GTK CSD support has been disabled at compile time.

As a result:

Firefox ignores GTK headerbar theming

Window control buttons (close/minimize/maximize) fall back to Adwaita styling

GTK themes that correctly work for all other GTK applications (including GTK4 apps) cannot affect Firefox window decorations

This is a regression compared to earlier GTK3-based Firefox versions where CSD and theming worked as expected

This effectively removes the ability for users and distributions to have Firefox integrate visually with their GTK desktop environment.

Steps to Reproduce

Run Firefox on Linux with:

GNOME

Wayland session

GTK4-based build

Use a GTK theme that customizes headerbars and window buttons (e.g. macOS-style button layouts)

Open Firefox

Actual results:

Firefox window decorations do not follow the active GTK theme

Window buttons are rendered using Firefox’s internal/adwaita-like styling

GTK theme assets for window controls are ignored

The CSD-related preference is completely missing from about:config

Expected results:

Firefox should support GTK client-side decorations on Linux

GTK themes should be able to style Firefox headerbars consistently with other GTK applications

The CSD feature should not be silently removed at compile time without fallback or documentation

Linux desktop integration should not regress compared to GTK3-based builds

Comment 1

[DFM]

Additional Information

Desktop: GNOME

Display server: Wayland

Toolkit: GTK4

Distribution: Debian-based

Build: Firefox-derived (LibreWolf), but the issue appears to be upstream GTK4 / Firefox related

This issue is not related to unsupported theming, but to the absence of GTK CSD support in GTK4 Firefox builds, which prevents window controls from being provided by GTK at all.

Comment 2

[BugBot [:suhaib / :marco]]

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 3

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

I don't understand what do you mean by Gtk4. We don't support hat yet and There's ongoing effort to backport Firefox to Gtk4 at Bug 1701123.

Comment 4

[DFM]

Thanks for the clarification.

To clarify: I am not claiming that Firefox is a fully GTK4-based application yet.

What I am referring to is the behavior of current Linux GTK builds on Wayland, where client-side decorations and GTK headerbar integration appear to be absent or disabled compared to previous GTK3-based Firefox versions.

The main issue is that GTK window controls / headerbar theming are no longer exposed to the GTK theme, and the preference

widget.gtk.client-side-decoration.enabled

is completely missing, suggesting that CSD support is disabled at build time.

This results in a regression for GTK theming and window controls on Linux, independent of whether Firefox is considered GTK3 or GTK4 internally.

If this issue is better tracked as part of existing GTK / Wayland integration work, I’m happy to adjust or move the report accordingly.

Comment 5

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

Is that a recent regression? If so, can you try to find broken commit by mozregression tool?
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems?rd=Bug_info_Firefox#Use_Mozregression_tool
Thanks.

Comment 6

[DFM]

I ran mozregression locally.

Regression range:
Last good revision:
8cade2d76b6c848b26ab00ed9cbf0ed718fecccf

First bad revision:
db25c2152ea0ff3d16f330624b838a108d0222d2

Autoland pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=8cade2d76b6c848b26ab00ed9cbf0ed718fecccf&tochange=db25c2152ea0ff3d16f330624b838a108d0222d2

This is where GTK client-side window controls stop following the GTK theme on Wayland.

Comment 7

[BugBot [:suhaib / :marco]]

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

For more information, please visit BugBot documentation.

Comment 8

[Emilio Cobos Álvarez [:emilio]]

This is pretty much intended, because we can't draw arbitrary titlebar icons with a random theme without being able to set the foreground / background colors. So what we follow is the icon theme.

Comment 9

[DFM]

Thanks for the clarification.

I understand the technical limitation regarding arbitrary titlebar icons and the lack of reliable foreground/background color APIs in GTK.

However, from a user perspective this is still a regression:

Firefox previously followed GTK client-side decorations and respected GTK window controls, including theme-provided titlebar buttons. This changed in a specific regression window (see mozregression results above), which strongly suggests a behavioral change rather than long-standing design intent.

GTK CSD exists specifically to allow applications to integrate with the desktop environment’s window controls and theming. Other GTK applications manage to do this without fully custom-drawing their own controls.

Even if following the icon theme is intentional now, the result is that Firefox no longer integrates visually with GTK themes on Wayland, which breaks consistency with the rest of the desktop.

Could this be reconsidered as either:

• a configurable option (e.g. native GTK CSD vs Firefox-drawn),
• or at least documented clearly as an intentional change/regression in GTK integration?

I’m happy to provide further testing or context if needed.

Comment 10

[DFM]

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

This is pretty much intended, because we can't draw arbitrary titlebar icons with a random theme without being able to set the foreground / background colors. So what we follow is the icon theme.

Thanks for clarifying that this behavior is intentional.

In that case, I think this issue should be reclassified from a bug to an enhancement or UX regression request.

While I understand the technical limitations around drawing titlebar icons and handling foreground/background colors, the resulting behavior is still a noticeable regression in user experience. Firefox previously followed GTK client-side decorations and respected theme-provided window controls, and this behavior changed within a clearly identifiable regression window.

GTK CSD exists specifically to allow applications to integrate with the desktop environment’s window controls and theming. Losing that integration on Wayland breaks visual consistency with the rest of the GTK desktop, especially for users relying on custom window controls provided by their GTK theme.

This affects all GTK themes that provide custom window controls, not just a single theme, and it breaks visual consistency across the desktop environment.

Even if the current behavior is intentional from an implementation standpoint, the UX impact seems significant enough that it should be tracked explicitly as an enhancement or UX regression rather than closed as a non-issue.

Could this issue be moved accordingly so the trade-offs and potential future options (for example configurability) can be tracked properly?

Comment 11

[Jens Stutte [:jstutte]]

:stransky in comment 3:

We don't support hat yet and There's ongoing effort to backport Firefox to Gtk4 at Bug 1701123.

Sounds indeed like an enhancement that maybe blocks 1701123 then? Also marking it as regression makes it show up as important bug in some release management queries, albeit having the regression range is great, of course. Thanks!

Comment 12

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

Gtk4 / Bug 1701123 is experimental approach and we're not considering to ship it any time soon (if even).