Closed Bug 1519202 Opened 5 years ago Closed 19 days ago

[GTK3] Completely remove top/right padding for window buttons

Categories

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

Product:
Core
Component:
Widget: Gtk
Platform:
Desktop
Linux
Type:
defect

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1560702

People

(Reporter: aros, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(6 files)

Screenshot_Nightly_20190110.png
91.88 KB, image/png
Details
top.png
70.70 KB, image/png
Details
Padding on my system (Firefox is maximized)
4.36 KB, image/png
Details
Chromium with CSDs can be closed by clicking next to the close button
1.40 KB, image/png
Details
gtk4-demo.png
3.81 KB, image/png
Details
newtab.png
11.79 KB, image/png
Details

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:64.0) Gecko/20100101 Firefox/64.0

Steps to reproduce:

Can we please discuss the top and right padding for [titlebar] window buttons?

  • All versions of Windows don't have it whatsoever.
  • A lot of popular XFCE/KDE windows manager themes also don't have it.

What's the reason Firefox has it?

Currently you cannot blindly move the mouse cursor to the top right corner and close Firefox which works for all other applications here in Windows/XFCE/KDE.

If Mozilla UX designers believe the padding is necessary, please give us an option to remove it completely.

Thank you.

Blocks: gtktitlebar
Component: Untriaged → Widget: Gtk
OS: Unspecified → Linux
Product: Firefox → Core
Hardware: Unspecified → Desktop

This has been happening on KDE Neon user edition since CSD in Firefox came available, I think.
Can be seen in this picture: https://i.imgur.com/v49T8t7.png (the window is maximized even though the max/unmax button isn't rectangular as usually in Breeze theme)
It's quite annoying as one can't just swipe the mouse to the up right corner to close, like in any other Windows or Linux desktop environments I have used.

Do other Gtk3 applications (gedit for instance) have the padding in maximized state? Thanks.

Flags: needinfo?(aros)
Priority: -- → P3

On my KDE Neon Plasma desktop:

I tried gedit and then Nautilus, and indeed the padding bug appears in them too: https://i.imgur.com/f7bZ7Z4.png

I have also used some apps that AFAIK use GTK3 but work as they should:
remmina (1.2.0-rcgit.29+dfsg-1ubuntu1)
thunderbird (60.7.0)
libreoffice (1:6.0.7-0ubuntu0.18.04.6)
synaptic (0.84.3ubuntu1)
All those non-affected apps seem to use the default KDE/kwin titlebar.
Both gedit and Nautilus seem to use some kind of CSD titlebars.

So for my system the bug seems to appear in (all?) GTK3 + CSD apps.

On my 1680x1050 pixels screen it looks like the padding is:
Firefox: 3 px from top and 6 from right
gedit: 9 px from top and 6 from right
Nautilus: 8 px from top and 6 from right

(P.S. In the image of my previous comment the "1 px border..." on left doesn't seem related to this, it is a KDE bug.)

(In reply to Martin Stránský [:stransky] from comment #2)

Do other Gtk3 applications (gedit for instance) have the padding in maximized state? Thanks.

GTK3 applications do not have their own window decorations, so your question doesn't make sense.

I'm now running XFCE4/XFWM and there's no padding at all - all maximized windows can be closed by moving the mouse to the top right corner.

Flags: needinfo?(aros)

(In reply to Martin Stránský [:stransky] from comment #2)

Do other Gtk3 applications (gedit for instance) have the padding in maximized state? Thanks.

No, gedit nor gtk3-demo don't have any. Meaning you can close them by clicking in the top right corner, but this doesn't work in Firefox.

(In reply to mthw0 from comment #5)

(In reply to Martin Stránský [:stransky] from comment #2)

Do other Gtk3 applications (gedit for instance) have the padding in maximized state? Thanks.

No, gedit nor gtk3-demo don't have any. Meaning you can close them by
clicking in the top right corner, but this doesn't work in Firefox.

Can you try to run browser toolbox and find where the padding comes from by inspector tool? (https://developer.mozilla.org/en-US/docs/Tools/Browser_Toolbox)
Thanks.

Is this any help? I mean, I don't know what I am doing. https://imgur.com/a/yiHXQBK

(In reply to mthw0 from comment #7)

Is this any help? I mean, I don't know what I am doing.
https://imgur.com/a/yiHXQBK

Almost there. That tool allows you to inspect property of the elements and also source of the property, if that's computed or derived from toolkit. You need to find another inspector window with the actual button properties.

I have found something that might be related: https://imgur.com/a/ZHiRTUv

So, It is possilbe to fix this issue by setting margin-right and margin-top to -X px, But the problem is that the X value needs to be different for different themes. For example Breeze theme has quite small buttons that would need a lot of moving. See: https://imgur.com/a/lpRbd3c. Or in other words, the area that reacts to mouse clicks is button-image-size dependent and it shouldn't be.

Attached image top.png —

(In reply to Martin Stránský [:stransky] from comment #6)

(In reply to mthw0 from comment #5)

(In reply to Martin Stránský [:stransky] from comment #2)

Do other Gtk3 applications (gedit for instance) have the padding in maximized state? Thanks.

No, gedit nor gtk3-demo don't have any. Meaning you can close them by
clicking in the top right corner, but this doesn't work in Firefox.

Can you try to run browser toolbox and find where the padding comes from by inspector tool? (https://developer.mozilla.org/en-US/docs/Tools/Browser_Toolbox)
Thanks.

I wasn't able to find any padding using the browser toolbox but I've discovered an interesting detail. My new tab button is at the left top corner and it has no padding at all, i.e. it behaves exactly how the minimize/maximize/close buttons should work in theory.

AFAICT there are two issues resulting in the current situation:

  1. When using a gtk theme that has window buttons big enough like Qohir-win, you can close maximized windows of apps like gtk3-demo, pamac, nautilus, ... But you cannot close firefox. This can be fixed by setting margin-top and margin-right to -X px.
  2. If you use a gtk theme with smaller window buttons like Adwaita (default for gnome), Breeze (default for KDE) or generally ~90% of other themes, you cannot close ANY window by clicking the top right corner, simply because the button is too small and thus too far from where you are clicking. This is a gtk bug or feature.

(In reply to mthw0 from comment #14)

AFAICT there are two issues resulting in the current situation:

  1. When using a gtk theme that has window buttons big enough like Qohir-win, you can close maximized windows of apps like gtk3-demo, pamac, nautilus, ... But you cannot close firefox. This can be fixed by setting margin-top and margin-right to -X px.
  2. If you use a gtk theme with smaller window buttons like Adwaita (default for gnome), Breeze (default for KDE) or generally ~90% of other themes, you cannot close ANY window by clicking the top right corner, simply because the button is too small and thus too far from where you are clicking. This is a gtk bug or feature.

I'm not sure what you're talking about. Firefox on Linux is rendering its own title bar. It does not depend on a window manager and/or your currently selected window decorations theme.

I'm not sure what you're talking about. Firefox on Linux is rendering its own title bar. It does not depend on a window manager and/or your currently selected window decorations theme.

Yes, it doesn't depend on window decoration themes when using CSDs, but it does depend on a GTK theme, that's where the button size comes from.

That's why I said that, the problem isn't caused by the button having a padding or a margin. I believe it's caused by you not being able to close the window by clicking in the area around it. In chromium this is possible, see the attachment. The solution would be to implement this also in Firefox.

(In reply to mthw0 from comment #5)

(In reply to Martin Stránský [:stransky] from comment #2)

Do other Gtk3 applications (gedit for instance) have the padding in maximized state? Thanks.

No, gedit nor gtk3-demo don't have any. Meaning you can close them by clicking in the top right corner, but this doesn't work in Firefox.

To be more exact, only if the GTK theme you use has window buttons big enough, like Qogir-win. Otherwise you cannot. Also this sounds more like a GTK bug.

Strangely this issue doesn't affect Thunderbird 78.2.2.

Severity: normal → S3

Emilio, any idea how to make the padding clickable as close button?
Thanks.

Flags: needinfo?(emilio)

So there are various boxes here:

  • titlebar button box
  • The titlebar toolbarbuttons (which are the actual close buttons etc)

There's various things that could be done here, the padding of the button is clickable tho. The right margin can be tweaked by not returning a border size for the button box here.

That said, this seems like an issue with every GTK3 app, right?

Flags: needinfo?(emilio)

(In reply to Emilio Cobos Álvarez (:emilio) from comment #20)

So there are various boxes here:

  • titlebar button box
  • The titlebar toolbarbuttons (which are the actual close buttons etc)

There's various things that could be done here, the padding of the button is clickable tho. The right margin can be tweaked by not returning a border size for the button box here.

That said, this seems like an issue with every GTK3 app, right?

Every GTK3 app which uses CSD. Not all of them do.

Attached image gtk4-demo.png —

GTK4 CSD is a lot worse: on the screenshot you can see that the mouse pointer does nothing 10 pixels away from the right topmost corner.

I've filed a bug report against GTK4 but I'm 99.999999% sure it will be closed as INVALID/WONTFIX/THIS WORKS AS INTENDED.

https://gitlab.gnome.org/GNOME/gtk/-/issues/5307

Anyways, this bug report has nothing to do with GTK's CSD because Firefox under Linux renders its entire window including the title bar and it doesn't use GTK for that.

Earlier I said Thunderbird wasn't affected but its recent versions are broken in this regard as well.

Perhaps Thunderbird 78.2.2 used GTK2 or a version of GTK3 which had a more human friendly CSD implementation.

Attached image newtab.png —

This bug must be relatively easy to fix because Firefox tabs have zero top padding and they are clickable if you move the mouse along the top of the screen.

Also, if you move the Create new tab button to the left side, it's also clickable when the mouse is in the left top corner.

(In reply to Emilio Cobos Álvarez (:emilio) from comment #20)

So there are various boxes here:

  • titlebar button box
  • The titlebar toolbarbuttons (which are the actual close buttons etc)

There's various things that could be done here, the padding of the button is clickable tho. The right margin can be tweaked by not returning a border size for the button box here.

That said, this seems like an issue with every GTK3 app, right?

Yes. I wonder if we may hack it a bit on Firefox side.

If it helps, here's a workaround I found for Fedora 38 (with KDE).
Now when I blindly move the mouse in the top-right corner, the close button is actually highlighted and clickable.

Add the following in your userChrome.css file:
Note that the "top" and "right" values might need to be tweaked depending on resolution or scaling settings.

@namespace url("http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul");

.titlebar-buttonbox-container{
position: fixed;
top:-2px;
right:-8px;
height: 0px;
display: block !important;
}

Sadly Thunderbird is now broken as well.

Still unresolved 5 years in.

Actually it is, see bug 1560702.

Status: UNCONFIRMED → RESOLVED
Closed: 19 days ago
Duplicate of bug: 1560702
Resolution: --- → DUPLICATE

I can reproduce this with Firefox 124.0.2 running on Fedora 39/XFCE.

Status: RESOLVED → UNCONFIRMED
No longer duplicate of bug: 1560702
Resolution: DUPLICATE → ---

Didn't know the fix is landed only in Firefox 125.

Status: UNCONFIRMED → RESOLVED
Closed: 19 days ago → 19 days ago
Resolution: --- → INVALID
Duplicate of bug: 1560702
Resolution: INVALID → DUPLICATE

Confirming fixed in 125 beta8. Thanks a ton.

What I still don't understand is why I have to

export GTK_CSD=1

to hide the titlebar even in Firefox 125.

Please file a separate bug: What environment? Do you have gtk3-nocsd by any chance?

(In reply to Emilio Cobos Álvarez (:emilio) from comment #36)

Please file a separate bug: What environment? Do you have gtk3-nocsd by any chance?

It's quite unusual. No, I don't have gtk3-nocsd installed.

Steps to reproduce:

  1. Login into XFCE
  2. Open any terminal application (XFCE terminal/xterm/whatever)
  3. xhost +SI:localuser:anotheruser
  4. sudo su - anotheruser
  5. export DISPLAY=:0
  6. firefox

Somehow when Firefox doesn't see/find certain environmental variables it resorts to using SSD.

According to env, the anotheruser user is missing the following variables:

DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
DESKTOP_SESSION=Xfce Session
PANEL_GDK_CORE_DEVICE_EVENTS=0
SESSION_MANAGER=local/unix:@/tmp/.ICE-unix/1234,unix/unix:/tmp/.ICE-unix/1234
XDG_CONFIG_DIRS=/etc/xdg
XDG_CURRENT_DESKTOP=XFCE
XDG_DATA_DIRS=/usr/local/share:/usr/share
XDG_MENU_PREFIX=xfce-
XDG_RUNTIME_DIR=/run/user/1000
XDG_SEAT=seat0
XDG_SESSION_CLASS=user
XDG_SESSION_ID=2
XDG_SESSION_TYPE=x11
XDG_VTNR=7

I'm pretty sure Firefox is checking either for DESKTOP_SESSION or XDG_CURRENT_DESKTOP and when it doesn't see them, it uses SSD.

Please tell me if it needs a separate bug report. Maybe such a configuration is not supported.

Lol, exactly like that:

widget/gtk/WidgetUtilsGtk.cpp:

// Getting a reliable identifier is quite tricky. We try to use the standard
// XDG_CURRENT_DESKTOP environment first, _NET_WM_NAME later, and a set of
// legacy / non-standard environment variables otherwise.
      };
      if (const char* currentDesktop = Env("XDG_CURRENT_DESKTOP")) {
        return nsCString(currentDesktop);

widget/gtk/nsWindow.cpp:

    }
    // TODO: Consider switching this to GetDesktopEnvironmentIdentifier().
    const char* currentDesktop = getenv("XDG_CURRENT_DESKTOP");
    if (!currentDesktop) {
      return GTK_DECORATION_NONE;
    }

Does this warrant a bug report?

Firefox really hates not running under some $XDG_CURRENT_DESKTOP.

Yeah, please do. We should probably just do what ^ says and switch to that :)

Bug 1889934

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: