GTK Titlebar Buttons / Window Controls Display Incorrectly
Categories
(Core :: Widget: Gtk, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox142 | --- | fixed |
People
(Reporter: lordmethenor, Assigned: emilio)
References
Details
Attachments
(5 files)
Screenshot From 2025-06-30 00-27-55.png
Steps to reproduce:
- Apply GTK theme (I used adw-gtk3)
- Open Firefox
Actual results:
Titlebar window control buttons misaligned and missing background
Expected results:
Titlebar should have aligned properly according to GTK theme (OR Libadwaita styling, if the change was intentional).
This is what happens in Firefox 139.
It seems like Firefox is trying to apply a LibAdwaita-style titlebar in the last several updates, starting with default libadwaita colors and now including libadwaita-style window controls.
An unintended side effect has been enforcing an INCORRECT position/placement for the window controls, even though they have the right icon.
In the past, applying a libadwaita-based GTK3 theme like adw-gtk3 would solve this issue, but now, the hardcoded icon is more incorrect. There are options in about:config for disabling the libadwaita colors and non-native titlebar buttons, but they do not seem to function. Really hoping this change can be reverted, at least by config option, in Firefox 140.x or 141, even if a proper libadwaita close button by default will be implemented some time later.
|
Reporter | |
Comment 1•4 months ago
|
||
|
||
Comment 2•4 months ago
|
||
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.
Slightly relevant topic,
On KDE, Firefox versions 140-142, in safe mode, arch pacman or flatpak.. I noticed these -moz-symbolic-icon(window-minimize-symbolic) buttons are rendering as if GTK style buttons. But another User on reddit (kde as well) seems to be defaulting to KDE's QT style buttons. Being as kde is QT focused, it would make more sense that I would also have these QT buttons as well. Somehow that isn't the case across multiple packaged/unmodified firefox's, making them all look non-native.
|
||
Comment 4•4 months ago
|
||
(In reply to soulhotel from comment #3)
Slightly relevant topic,
On KDE, Firefox versions 140-142, in safe mode, arch pacman or flatpak.. I noticed these
-moz-symbolic-icon(window-minimize-symbolic)buttons are rendering as if GTK style buttons. But another User on reddit (kde as well) seems to be defaulting to KDE's QT style buttons. Being as kde is QT focused, it would make more sense that I would also have these QT buttons as well. Somehow that isn't the case across multiple packaged/unmodified firefox's, making them all look non-native.
Fx is now using the currently set icon theme for the window control buttons. Tested just now with gnome-tweaks-tools, fx seems to need a restart though. Other titlebar icons (up/down/+) are probably fx' own icons as I can not see any change in those.
For the problem that the reporter is talking about I can't seem to spot a difference between versions. Will call for tech support. :)
|
Assignee | |
Comment 5•4 months ago
|
||
Yes, that's correct, we now just use the icon theme for the titlebar buttons. I'm assuming that comment 0 is about the spacing from the close button to the window edge?
It is possible that due to how we rendered these the adw-gtk3 theme "fixed" / worked around it, and now no longer does.
That said, the reason it's "mispositioned" is because we allow closing the window clicking all the way to the edge of the window. If we shift the close button at least in the naive way we'd lose that.
|
|
Assignee | |
Comment 6•4 months ago
|
||
|
||
Updated•4 months ago
|
|
|
Reporter | |
Comment 7•4 months ago
|
||
It seems LibAdwaita based apps can be closed from the corner without actually touching the close button. If this is not desireable behavior, could close button padding be restored through an about:config option? There is no other browser (or app) I know of that forces the close button to the edge of the window.
Also, that isn't the only change between the versions in the screenshots. I added two screenshots because I could not simultaneously focus each window, but the defect is visible in both. Notice how, even when the mouse is not hovering over the 'close' button, there is a grey circle behind it. In Firefox 140, this gray circle/backdrop is missing. I gather this is a bug because when I do hover over it, the background appears in its darkened hover state. This is also something I have not seen before in any other application.
|
|
Assignee | |
Comment 8•4 months ago
|
||
Also, that isn't the only change between the versions in the screenshots. I added two screenshots because I could not simultaneously focus each window, but the defect is visible in both. Notice how, even when the mouse is not hovering over the 'close' button, there is a grey circle behind it. In Firefox 140, this gray circle/backdrop is missing. I gather this is a bug because when I do hover over it, the background appears in its darkened hover state. This is also something I have not seen before in any other application.
That is intended. It is the Adwaita GTK3/GTK4 behavior, and also Breeze's default behavior. We could special-case GNOME desktop environment I guess but it'd be a bit ugly.
|
|
Reporter | |
Comment 9•4 months ago
|
||
(In reply to Emilio Cobos Álvarez (:emilio) from comment #8)
Also, that isn't the only change between the versions in the screenshots. I added two screenshots because I could not simultaneously focus each window, but the defect is visible in both. Notice how, even when the mouse is not hovering over the 'close' button, there is a grey circle behind it. In Firefox 140, this gray circle/backdrop is missing. I gather this is a bug because when I do hover over it, the background appears in its darkened hover state. This is also something I have not seen before in any other application.
That is intended. It is the Adwaita GTK3/GTK4 behavior, and also Breeze's default behavior. We could special-case GNOME desktop environment I guess but it'd be a bit ugly.
Do you mean the result would be ugly or carving out a special case would be ugly? I recommend this special case because while modern GNOME does technically use the old Adwaita GTK3/GTK4 theme, the visual appearance of almost all apps on GNOME is Libadwaita with the margin and backdrop.
This means non libadwaita apps on GNOME look very dated. As Firefox, not GNOME Web, is shipped with GNOME on so many distros (like mine, Fedora), this incongruity is the first impression users had and could only be changed with an unofficial GTK3/4 theme like adw-gtk3.
That is the whole reason Firefox is now hardcoding the libadwaita colors, right? Because before, desktops shipping vanilla GNOME would theme Firefox's titlebar and window controls with old Adwaita?
If so, I can't see any justification for hardcoding the Libadwaita colors by default while also hardcoding the old Adwaita window control icon behavior. Distros or users with different GTK themes now have to disable an advanced configuration option to use their system theme. Please, either use the libadwaita window controls, or let the GTK theme chose as in v139, at least as a config value.
There is also widget.gtk.libadwaita-colors.enabled. I don't know if this isn't already special-case for GNOME, as other DEs ship other GTK themes depending on distro, but I think adding the window control backdrop would make sense if you don't want to make a new config.
tl;dr if Firefox's headerbar is looking libadwaita by default on Linux, it should display the window controls as libadwaita apps do.
Sorry if this got a little ranty. It's really not Firefox's or its devs' fault that this is so messy. Thank you for all the good work you do for the web!
|
|
Assignee | |
Comment 10•4 months ago
|
||
We're getting the spacing from the wrong box (the headerbar, rather than
the button box container). Even with that, some themes would use
additional ways of creating spacing (paddings or margins). So in
practice the 6px between buttons is just incorrect.
Instead, just use the Adwaita spacing. We're using Adwaita styling
anyways, so this makes the headerbar match perfectly in Gnome.
With the Breeze theme (for KDE), this patch is closer than before
(even though personally I might take some time to get used to it).
We can also reduce it back to 6px between buttons in some DEs, if
somebody complains, which is what we're shipping, effectively.
|
|
Assignee | |
Comment 11•4 months ago
|
||
|
|
Assignee | |
Updated•4 months ago
|
|
|
Reporter | |
Comment 12•4 months ago
|
||
Is there any way to test the changes?
|
|
Assignee | |
Comment 13•4 months ago
|
||
https://treeherder.mozilla.org/jobs?repo=try&landoCommitID=140945 should have some builds in a few hours, you can click on the "B", and download a targz with a build.
|
||
Comment 14•4 months ago
|
||
|
||
Comment 15•4 months ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/572f8c0a1d54
https://hg.mozilla.org/mozilla-central/rev/772a6ef398b5
https://hg.mozilla.org/mozilla-central/rev/9dce2098379d
|
||
Updated•4 months ago
|
|
|
Reporter | |
Comment 16•3 months ago
|
||
I'm still having some issues with this in the 142 beta. My close buttons position correctly, but they still do not have background unless I revert to default adwaita theme, which then causes other theme issues (border width, shadow, and corner radius).
Is it possible to attach screenshots to the comment or otherwise send them to the maintainer?
|
|
Assignee | |
Comment 17•3 months ago
|
||
File a separate bug please, but yes, there's an attach file button where you can add screenshots
Description
•