Closed Bug 1827137 Opened 2 years ago Closed 2 years ago

Firefox 111 shows titlebar AND custom window buttons if gtk3-nocsd has been manually installed

Categories

(Core :: Widget: Gtk, defect)

Firefox 111
Desktop
Linux
defect

Tracking

()

RESOLVED FIXED
114 Branch
Tracking Status
firefox-esr102 --- disabled
firefox112 --- wontfix
firefox113 --- wontfix
firefox114 --- fixed

People

(Reporter: allo, Assigned: emilio)

References

(Regressed 1 open bug, Regression)

Details

(Keywords: regression)

Attachments

(2 files)

Since the upgrade to Firefox 111, Firefox by default uses the system titlebar (as it should) of KDE, but also shows next to the menu own close/minimize/maximize buttons.

When I click "customize toolbar" the checkbox "title bar" is unchecked, even when Firefox shows a titlebar. Clicking it fixes the problem, but on a fresh profile the problem is the same.

This is a regression from Firefox 110 which had no such problems.

I could not reproduce the issue on neither Ubuntu 20.04 using FF build 110.0.1 nor on Fedora KDE using FF build 111.0.
Does the problem still happen if you start Firefox in Safe Mode? (Safe Mode disables add-ons, extensions and themes, hardware acceleration and some JavaScript stuff in order to exclude some possible reasons for problems.) See https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode
Also can you please add the exact version of you system. Thank you.

Flags: needinfo?(allo)

Debian testing, version: Firefox 111.0.1-1 from Debian sid (I think since the freeze Debian testing only uses Firefox ESR versions)

When launching Firefox from the shell, it does not have a window decoration (i.e. the state "title bar = off" is applied as it is shown in the settings), when launching it from the KDE panel it has a title bar and the own window buttons.
Both tests with .mozilla moved aside, so Firefox creates a completely new profile.

Usually Firefox should default to having a title bar under Linux, if this didn't change between 110 and 111.

I do not know why it has a titlebar when title bar is (probably wrongly) disabled when launching from the panel and not when launching from a terminal. But the behaviour when launching from a terminal is at least consistent with the setting and with not having two sets of window buttons.

Flags: needinfo?(allo)

Could not reproduce on ESR build 102.10.0esr on Fedora KDE either using terminal to open browser.

QA Whiteboard: QA-not-reproducible

Could not reproduce on ESR build 102.10.0es

102 to 110 didn't have the problem for me. No ESR versions, but I guess there are no large differences in the code base of the ESR and the non-ESR version.

Component: Toolbars and Customization → Widget: Gtk
Product: Firefox → Core

KDE X11, Debian Testing
WFM.
bug 1812289 has enabled client side decorations (Firefox window without system titlebar) by default.
If titlebar is not disabled for you in some cases, it might be caused by manually changed KDE settings.

Titlebar was disabled as expected when I started Firefox 111 by

  • mozregression
    $ pip3 install mozregression
    $ mozregression --launch 111.0.1
  • terminal
    $ sudo apt install -t unstable firefox
    $ firefox
  • start menu
  • pinned icon in taskbar

Bug 1812289 at least explains why it happens. But it should probably not be the default on KDE systems, as there server-side decorations are the default and used on all programs.

This still does not resolve this bug to explain why Firefox seems not to always disable server-side decorations when client-side decorations are used.

Btw. will there be an enterprise policy to enable native (server-side) titlebars by default?

Works for me too: Is there any environment variable that you have that could affect this? Can you post the output of env | grep -i 'moz\|gtk'?

Re. enterprise policies: I'm not sure, but there's a pref (browser.tabs.inTitlebar = 0)

I created Bug 1827227 for changing the default on KDE systems to server-side decorations, as KDE desktops mostly consist of server-side decorated programs, where possible even for Gtk applications.

GTK_IM_MODULE=ibus
GTK_RC_FILES=/etc/gtk/gtkrc:/home/user/.gtkrc:/home/user/.config/gtkrc
GTK_MODULES=gail:atk-bridge
LD_PRELOAD=libgtk3-nocsd.so.0
GTK2_RC_FILES=/etc/gtk-2.0/gtkrc:/home/user/.gtkrc-2.0:/home/user/.config/gtkrc-2.0
GTK_CSD=0
GTK_OVERLAY_SCROLLING=0
GTK3_MODULES=xapp-gtk3-module

Re. enterprise policies: I'm not sure, but there's a pref (browser.tabs.inTitlebar = 0)

I know and it is easy to reach in the UI, but when developing and testing websites I often use fresh profiles with few settings and addons and there I now get client-side decorations or when using a launcher in the panel client-side buttons and server-side decorations.

GTK_CSD=0 and libgtk3-nocsd.so.0 seem suspicious here. I guess GTK is disabling CSD but Firefox still thinks it's enabled, which causes the issue described in comment 0. Do you know where does libgk3-nocsd come from?

Flags: needinfo?(allo)

First the output from running in a terminal (the other was from running from the panel, using a script that first shows a message with the environment variables):

GTK_IM_MODULE=ibus
GTK_RC_FILES=/etc/gtk/gtkrc:/home/user/.gtkrc:/home/user/.config/gtkrc
GTK_MODULES=gail:atk-bridge
GTK2_RC_FILES=/etc/gtk-2.0/gtkrc:/home/user/.gtkrc-2.0:/home/user/.config/gtkrc-2.0
GTK_CSD=0
GTK_OVERLAY_SCROLLING=0
GTK3_MODULES=xapp-gtk3-module

(I don't have gtk3-nocsd installed and according to synaptic no package depends on it. It's also possible to break things by adding custom titlebar settings in KDE Settings > Window Management > Window Rules.)

Adding "unset LD_PRELOAD" to the script, I get a Firefox with CSD.

the library comes from the gtk-nocsd package and mostly does what the name says, trying to get gnome programs to use server-side decorations.

I am not sure why my terminal neither has the LD_PRELOAD variable set nor inherits it as it is launched from the same panel.
Maybe the terminal window already uses the preloaded library and then unsets the LD_PRELOAD variable? I wonder if programs like firefox then inherit the preloading or if it is lost that way and would need to be set again in the .bashrc (or what shell one uses).

Flags: needinfo?(allo)

(I don't have gtk3-nocsd installed and according to synaptic no package depends on it. It's also possible to break things by adding custom titlebar settings in KDE Settings > Window Management > Window Rules.)

I guess Firefox should detect if the window is decorated and then hide the buttons.
As you said, window rules are the other option to force windows to use the KWin decoration, and should probably make the CSD buttons disappear as well.

KDE X11, Debian Testing

  1. $ sudo apt install gtk3-nocsd
  2. logout&login
  3. $ mozregression --launch 111.0.1

Chrome & Chromium are not affected by gtk3-nocsd and keep using tabs-in-titlebar.

Status: UNCONFIRMED → NEW
QA Whiteboard: QA-not-reproducible
Ever confirmed: true
Summary: Firefox 111 shows titlebar AND custom window buttons by default under Linux → Firefox 111 shows titlebar AND custom window buttons if gtk3-nocsd has been manually installed

I wonder if it also affects systems on which the compositor really is broken or the window manager does not support compositing.

From the explanation how gtk3-nocsd works:

$LD_PRELOAD is used to override several Gdk and glib/gobject APIs to intercept related calls Gtk+ 3 uses to setup CSDs. For older versions of Gtk+ 3, while it is trying to initialize CSDs, it is led to believe that there is no compositor available, so CSDs are not added. For later Gtk+ 3 versions (3.16.1+), the gtk_window_set_titlebar method is reimplemented, as tricking Gtk+ 3 into thinking the compositor is disabled has side effects and is not sufficent anymore.

So the library triggers a Gtk fallback that is usually meant to be used on systems lacking certain capabilities. This would also apply on systems where the fallback is used because of lacking these things for real, probably because of graphic drivers or maybe minimalistic window managers that don't do compositing.

And for the Firefox feature: Maybe Firefox should (at least on the first run) follow the "GTK_CSD" environment variable, which was the official way to disable CSD.

I don't think there's a particularly nicer/easier way of doing this,
wdyt?

Assignee: nobody → emilio
Status: NEW → ASSIGNED
Pushed by ealvarez@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/956d24a99553 Allow overriding CSD support with GTK_CSD=0, so that gtk3-nocsd keeps working. r=stransky
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 114 Branch
Regressions: 1827563
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: