1885848 - Inactive window controls don't have circles or hovered appearance to indicate hitbox size with System theme on Ubuntu 23.10

Status: RESOLVED WORKSFORME

(Core :: Widget: Gtk, defect)

Description

[Kestrel]

Attachment: Comparison of inactive window control appearance

STR:

1. Ensure CSD titlebar is enabled with the System theme on Ubuntu 23.10.
2. Make the window inactive by focusing a different window.
3. Hover the cursor over the inactive window controls.

Inactive window controls don't have circles around them and do not respond to hover unlike the rest of the system.

With Bug 1560702 increasing the hitbox size, the lack of visual feedback may lead to accidental window closure and data loss.

• Lightweight themes not affected.
• Snap (gnome-42-2204) and flatpak (23.08 runtime) are not affected.
• Not a regression.
• Chromium (snap) unaffected.

Comment 1

[Kestrel]

Attachment: Example of a cursor location that will close the window without visual feedback

Comment 2

[Emilio Cobos Álvarez [:emilio]]

This is basically up to the GTK theme. We're giving it the right state. Gtk3 apps like gtk3-demo or gedit don't show hover feedback for these buttons on inactive windows. Some themes on GTK4 (like breeze) don't either...

Comment 3

[Kestrel]

Attachment: Comparison of active window control appearance

Bug 1885933 fixed inactive windows on Ubuntu 23.10 but now active windows don't show the circles or hovered state.

Comment 4

[Emilio Cobos Álvarez [:emilio]]

That makes no sense. That shouldn't have changed behaviour, will try to repro.

Comment 5

[Emilio Cobos Álvarez [:emilio]]

Prfft, that's a typo of mine in bug 1885933.

Comment 6

[❌ Anna Yeddi [:ayeddi] ❌ On leave until 2027-01-04]

Triaging it as access-S2 because in this case the state indication (hover) is missing for the Fx-level controls, clicking on which may cause the data loss for users (similarly to the other state - focus - indications missing as mentioned in the Accessibility triage guidelines).

Comment 7

[Maire Reavy [:mreavy]]

Hey Emilio, Reading your comment 5, it sounds like you know exactly how to fix this, and it would likely only take you a few minutes? This is currently an a11y S2, and fixing it would help one of our KRs. Can you take a look and try to make this fix? If the fix turns out to be trickier than you thought, please let me and Frank know. Thanks!

Comment 8

[Emilio Cobos Álvarez [:emilio]]

No. I broke something related to the buttons, that happened to "fix" this by not passing the right window state to GTK (but of course that broke the active window controls). That typo I fixed in https://bugzilla.mozilla.org/show_bug.cgi?id=1885933#c4

Basically, this is up to the GTK theme whether to react to this. I don't think this is easily fixable on our end. We could lie and tell GTK the window is always active I guess. But that probably regresses other themes so...

Comment 9

[Maire Reavy [:mreavy]]

Thanks, Emilio, for the quick reply, and is it true that this issue only affects Linux?

Comment 10

[Emilio Cobos Álvarez [:emilio]]

Correct (also only some themes like adwaita).

Comment 11

[Morgan Reschenberg [:morgan]]

(In reply to Anna Yeddi [:ayeddi] from comment #6)

Triaging it as access-S2 because in this case the state indication (hover) is missing for the Fx-level controls, clicking on which may cause the data loss for users (similarly to the other state - focus - indications missing as mentioned in the Accessibility triage guidelines).

Following up here to note that Anna's analysis is in line with our current triage guidelines and that I think this bug should remain an S2 due to the potential for data loss even if it is a smaller segment of our user base based on OS and/or theme.

Comment 12

[Karl Tomlinson (:karlt)]

I assume that the difference seen in comment 0 between Firefox and other apps is due to the difference between GTK+3 and GTK4 support from the theme (testable with gtk3-demo and gtk4-demo, for example).

• Both Adwaita (default) and Yaru (Ubuntu) GTK+3 themes have no :hover indication on :backdrop headerbar buttons. This seems to be consistent with lack of indication of :hover on :backdrop controls in general.
• Both Default and Yaru GTK4 themes do have indication of hover on :backdrop windowcontrols buttons and on many :backdrop controls, but not on non-windowcontrols buttons.
• The GTK+3 and GTK4 support in each theme looks intended to be similar, but the big difference in :hover:backdrop behavior and the inconsistency of GTK4 behavior with itself makes it's unclear where to start filing bugs on GTK.
• Porting to GTK4 (Bug 1701123) would be a huge amount of work and then Firefox would be inconsistent with GTK+3 apps.

I agree with Emilio in that there is not much we can do about visuals when wanting to look like other CSD GTK apps, such as when on a GNOME system, as is typically the case with Ubuntu. Trying to deceive GTK's theme rendering would be fickle and cause more problems than it would solve.

I've obsoleted some comments to clarify that the current behavior is the same as originally reported. (The behavior differed for a few days before it was corrected.

IIUC most of the problem with the lack of hover in the visuals is that the hitbox does not match up with the user's estimate of the size of the button.

• DWIM systems are unpredictable.
• It also doesn't seem right to aim for consistent appearance with the system but aim for different behavior of the corresponding buttons.
• That might be considered a missing feature in GTK, but there the expectation is for only the space between the button and the edge of the screen to trigger a close. In Firefox, the hitbox is extended even in unmaximized windows and around the entire perimeter of the close button, so this bug can result in accidental close of the window when trying to click the titlebar to raise, for example.
• Reverting the increase in hitbox size or limiting it to maximized windows and the space between the button and the edge of the screen would be a achievable way to substantially mitigate the issue. That's probably the first thing to do here.

This kind of issue is one of many expected from the use of client side decorations and particularly so when Firefox is on a system where other apps do not usually use client side decorations (KDE et al.).

• On such systems, there is no need to render buttons like GTK CSD buttons. We could consider using Firefox's own theme for buttons. IMO it would be better to not have CSD by default on these systems, but that is the only way to get tabs in the title bar and that benefit may been seen as outweighing the usability problems with CSD (bug 1812289).

Regarding the severity:

• There are workarounds available, clicking further away from the button or enabling "Title Bar" in "Customize Toolbar", which would usually mean S3.
• Accessibility triage guidelines are different. The feature is "available but difficult to use" implying S3, but the assessment here was IIUC based on hover state being considered equivalent in importance to "focus", the lack of which would be S2, or based on the data loss from closing a window.
• I don't have a good feel for why hover is as important as focus. Hover is hard to see at the best of times with many GTK themes. Touchscreens struggle with hover. Hover is more important in this case because the hitbox and button do not match. I'm keen to hear if hover indication is a need to have for other reasons.

Comment 13

[Kestrel]

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

Fixed by Bug 1964046.

Comment 14

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

Since the bug is closed, the stalled keyword is now meaningless.
For more information, please visit BugBot documentation.