1560702 - Custom window close button when title bar is disabled doesn't extend to edge of screen (Fitts' Law)

Status: RESOLVED FIXED

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

Description

[Markus Koller]

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

Steps to reproduce:

1. Disable title bar in "Customize"
2. Maximize the Firefox window
3. Move your mouse cursor all the way to the top-right corner of your screen (assuming a DE without a top panel, I'm on Linux/XFCE)
4. Click, with the intent of closing the window

Actual results:

Nothing happens, since the click area of the close button stops a few pixels short of the edge of the window.

Double-clicking results in unmaximizing the window.

Click-dragging results in unmaximizing and moving the window.

Expected results:

The close button should be triggered.

The click area should extend to the edge of the window, thus taking advantage of Infinite Width and observing Fitts' Law.

Comment 1

[Florencia Di Ciocco, NI to vbalducci]

Hi Markus,

I haven't been able to duplicate this bug on release 67, on two different ubuntu, one with 32 bit and one with 64. I believe this is a duplicate of bug 1506558, but since that one is also unconfirmed I will just assign and component and see if this can be fixed.

Meanwhile, maybe you can provide me with a bit more info.

Can you please download Firefox Nightly from here: https://nightly.mozilla.org/ and retest the problem and see if the issue still occurs there as well?
Does this issue occur with a fresh profile? you can find the steps here: https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles?redirectlocale=en-US&redirectslug=Managing-profiles#w_starting-the-profile-manager

Best regards, Flor.

Comment 2

[:Gijs (he/him)]

This is likely going to need more detailed steps so people can reproduce.

Comment 4

[sgl4kn]

Attachment: FF with title bar hidden

Comment 5

[sgl4kn]

Attachment: FF with titlebar shown (enlarge the preview)

Comment 6

[sgl4kn]

Don't quite understand how my bug can be a duplicate if it was opened 8 months before.

Anyhow, this is quite easy:

• For a fresh standard FF installation you'll get https://bug1560702.bmoattachments.org/attachment.cgi?id=9074570
• if you execute the mentioned steps below you'll get https://bugzilla.mozilla.org/attachment.cgi?id=9074568 and the window is not closed if the mouse is in the upper right corner

And yes, this is a huge usability issue, because most people don't look for a close button. They just move the mouse "blindly" to the very upper right corner and then expect the window to close if clicked.

1. Disable title bar in "Customize"
2. Maximize the Firefox window
3. Move your mouse cursor all the way to the top-right corner of your screen (assuming a DE without a top panel, I'm on Linux/XFCE)
4. Click, with the intent of closing the window

Comment 7

[:Gijs (he/him)]

(In reply to sgl4kn from comment #6)

• if you execute the mentioned steps below you'll get https://bugzilla.mozilla.org/attachment.cgi?id=9074568 and the window is not closed if the mouse is in the upper right corner

comment #1 suggests those steps in and of themselves are not sufficient to reproduce...

Comment 8

[Darkspirit]

Debian Testing, KDE, X11, Macbook Pro A1502
This is perfectly reproducible and I think there are similar bugs blocking bug 1283299.

1. Maxmize Firefox with browser.tabs.drawInTitlebar;false and move your mouse into the top-right corner:
   Close button is hovered. If you click, Firefox closes.
2. Maximize Firefox with browser.tabs.drawInTitlebar;true and move your mouse into the top-right corner:
   Close button is not hovered. If you click, you don't hit the close button. Window buttons are also smaller than usual.
   (The only other bug is that I'm unable to resize Firefox: bug 1453386)

Comment 9

[Markus Koller]

Attachment: FF with custom titlebar on XFCE

Comment 10

[Markus Koller]

@Florencia yes I can reproduce this on latest nightly 69.0a1 with a blank profile (except for setting browser.tabs.drawInTitlebar = true).

Since it looks different from @sgl4kn's screenshot, I guess this might be related to the Gtk theme/engine? I'm using https://github.com/numixproject/numix-gtk-theme for Gtk2 / Gtk3 / Xfwm.

Comment 12

[christian.ohrfandl]

I can reproduce this behaviour on a current Fedora 30 with most up to date Gnome shell and default Adwaita theme. I have a dual monitor setup from which the second one does not have any menu bars set on the top of the screen. When maximizing firefox (having title bar enabled) on the second screen, I can not press the x button when putting my cursor on the very corner where the x button (should) reside. When turning title bar off (i.e. having default gnome title bar), the mentioned action works as expected and triggers the click on the x button successfully (and implicitely closes the window).

Comment 13

[Jan Niklas Hasse]

btw: All Gtk applications that use GtkHeaderBar have this bug, see https://gitlab.gnome.org/GNOME/gtk/issues/583

Comment 16

[mmortal03]

I see this on Linux Mint 20.3, Firefox 103. Actually, not only are the buttons not clickable from the top edge of the screen, but you can only click on the actual symbols for each -- the region around each symbol for each button isn't even clickable.

Comment 17

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 3 duplicates.
:stransky, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 18

[Linore]

Reproducible
FF 110.0b2 (64-bit)
Ubuntu 22.10 kinetic
Resolution: 1920x1200
DE: GNOME 43.0
WM: Mutter
GTK Theme: Yaru-dark [GTK2/3]
Icon Theme: Yaru-dark
Font: Ubuntu 11

Comment 19

[ivor.hewitt]

This is/was annoying me also, I've found the following userchrome override to move the buttons up and right works for me:

  position: relative;
  top: -10px;
  left: 8px;
  z-index: 3;

  list-style-image: none !important;
  appearance: auto !important;
}```
Not sure if there's a cleaner/better way to do that.

Comment 20

[ivor.hewitt]

oops didn't put backticks on newlines:

.titlebar-button{
  position: relative;
  top: -10px;
  left: 8px;
  z-index: 3;

  list-style-image: none !important;
  appearance: auto !important;
}

Comment 21

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

Emilio, can we do anything here? For instance extend an active area of the corner titlebar button (which may be close)?
Thanks.

Comment 22

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1560702 - Improve hit boxes of titlebar buttons. r=stransky

In order to do it, expose the button padding to CSS via env(), and make
the buttons just use the regular drawing.

This slightly changes the padding to the end of the titlebar to match
one half of the inter-button spacing, rather that however much padding
the headerbar has.

We could improve on this slightly by also exposing the headerbar padding
and applying that to the last button, but that's not terribly easy to do
due to us supporting re-ordering of the titlebar buttons, and reversing
their placement, so it'd involve some rather hacky CSS. Not impossible,
but not trivial, and this looks good enough IMO.

Comment 23

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/f0fd4d27a589
Improve hit boxes of titlebar buttons. r=stransky,desktop-theme-reviewers,dao

Comment 24

[Natalia Csoregi [:nataliaCs]]

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