Open Bug 1539998 Opened 4 years ago Updated 8 months ago

Titlebar mouse clicks do not follow Gnome titlebar actions

Categories

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

66 Branch
defect

Tracking

()

Tracking Status
firefox-esr60 --- affected
firefox66 --- affected
firefox67 --- affected
firefox68 --- affected

People

(Reporter: frank.bruetting, Unassigned, NeedInfo)

References

(Regression)

Details

(Keywords: regression)

Attachments

(1 file)

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

Steps to reproduce:

I upgraded FF to v66, which brings the new header bar in Linux, where the empty bar is missing and instead the tabs are at the very top.

Actual results:

In Gnome settings I connected middle-mouse-click on window header bars to minimize them, this action now doesn’t work anymore with Firefox.

Expected results:

Action should work, but somehow this header bar is broken…

Would be cool if you may implement what I described in #1477507. There, the tabs then are below the header bar, but Firefox would be in sync with Gnome design guidelines and by the usage of regular header bars, such problems should not occurr.

Has STR: --- → yes

(In reply to Frank from comment #0)

In Gnome settings I connected middle-mouse-click on window header bars to minimize them, this action now doesn’t work anymore with Firefox.

  1. Can you explain how exactly you did that with detailed steps?
  2. Which version of Fedora are you using?

Thank you for your contribution!

Flags: needinfo?(zyklon87)

Of course. You install gnome-tweaks (not Gnome settings, sorry!), go to the “Window Titlebars” tab, and select “Minimize” for “Middle-Click”. Somehow, this new title bar is not responsive for such events…

Flags: needinfo?(zyklon87)

I have installed gnome-tweak-tool on Fedora 29 and set the middle-mouse-click to minimize windows as described in comment 2.
Then I have opened Firefox and middle-clicked the header bar. Doing this will open a new tab, just like it does by default in every OS type. Middle-clicking a tab will close it; middle-clicking the header har (not on a tab) will open up a new tab. Can you confirm that this is what you described as the issue, Frank?

Basically, the tweak to minimize the Firefox window does not work. This occurs the same in Nightly v68.0a1, Release v66.0.2 and ESR v60.6.1. I have also downloaded Firefox Release v65.0.2, but the issue occurs just the same; this could mean that the tweak tool could be the problem and not some modifications in Firefox66.

I also have to mention that if we were to compare to Chrome's behavior, then Chrome will behave and the tweak tool wishes and minimizes the windows if the header bar is middle-clicked.

I do not know if this issue could b considered a valid issue, so I will set its component as (Firefox) Tabbed Browser in the hope that a developer will pick it up and have a more appropriate opinion.

Thank you for your contribution!

Component: Untriaged → Tabbed Browser
Flags: needinfo?(zyklon87)
Component: Tabbed Browser → Widget: Gtk
Product: Firefox → Core
Regressed by: gtktitlebar

Yes, tab-related actions work perfectly fine, I just have an issue with this header bar minimizing action. Sorry for my not exactly precise description.

This minimizing issue exists since the update to FF v66 for me. I upgraded my Fedora Silverblue 29 to FSB30 since, but every other header bar works perfectly fine, whereas you altered the header bar all over – so I guess that you new bar is maybe missing something like an inherited header bar class, or something like that? I’ll check that tomorrow on my other machine, where I run Fedora 28!

Flags: needinfo?(zyklon87)
Duplicate of this bug: 1546646
Priority: -- → P2

It's because the middle click opens a new tab by default. I think it's better to be consistent here with Firefox default instead of getting actions from gnome-tweaks. I think we can have a preference for it (to switch Firefox / Gnome titlebar actions) but it's IMHO low priority now. But we can take a patch for it.

Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: P2 → P5
Summary: Middle-click doesn’t work anymore with the new header bar of v66 → Titlebar mouse clicks do not follow Gnome titlebar actions

It's because the middle click opens a new tab by default. I think it's better to be consistent here with Firefox default instead of getting actions from gnome-tweaks. I think we can have a preference for it (to switch Firefox / Gnome titlebar actions) but it's IMHO low priority now. But we can take a patch for it.

I’m not talking about the tab bar, I mean the bar with the address and the icons in it. There is no need for any tab-related action here, so it should adhere to desktop-environment-related actions, like every other program window does.

It used to work pretty fine for years – I don’t understand why those click-actions got deactivated without a good reason? I don’t see any advantage here.

(In reply to Frank from comment #7)

I’m not talking about the tab bar, I mean the bar with the address and the icons in it. There is no need for any tab-related action here, so it should adhere to desktop-environment-related actions, like every other program window does.

I'm confused. The address bar and the toolbar items next to it aren't in the title bar by default. Did you move them there? Otherwise, why do you expect title bar settings to affect this toolbar?

Flags: needinfo?(zyklon87)
Flags: needinfo?(zyklon87)

So why do you expect title bar settings to affect the area next to the address bar?

Ok, I uploaded a screen shot of my Firefox bars as of v66, with the areas where I expect to use DE-related mouse-click actions. Though it would be OK for me if the small area of the first bar would create a new tab. The second bar for me is the real header bar, as this bar contains the header itself (the address in the address bar) and all the other important icons/actions. The tab bar above is solely tab-related and therefore not that important, which is why I don’t consider this bar the header/title/main bar, even though it is above the more important second bar.

This is also one of the reasons why I proposed swapping those two bars in #1477507. Looking the same cross-platform doesn’t matter, because I (any surely 99% of all people) don’t swap operating systems every few minutes at work, but I instead swap between lots of different programs of the same operating system – and the only program which has totally out-of-place header bars is Firefox. And I don’t think that anyone else here swaps between Firefox instances with different operating systems below, as this doesn’t make any sense (except for some of the Firefox developers, which have to make sure that everything works everywhere, of course). No one swaps from Mac to Windows and expects everything to be the same, because pretty much everything is different, so minimal details like this don’t matter at all.

Duplicate of this bug: 1597636

Thank you Gingerbread Man and sorry for the duplicate bug! This one did not show up probably because "middle" is not is the title of the report.

Just adding a precision: I am not using Gnome (but KDE), and I am interested in having middle click to send Firefox to the background too. I think an option in about:config, disabled by default, to replace opening a new tab by sending to the background when middle-clicking on the empty area dedicated for tabs would be more than good enough for me. I also think that having middle-click middle click to send to the background in Firefox by default, even if is enabled in gnome-tweaks, would not be a great solution.

Great idea, I guess to be optimally compatible with all DE's, the about:config option should allow toggling between "new tab" (backward compatible behaviour) and "defer handling to window manager" - which would enable the middle click to minimize workflow if so configured in GNOME Tweaks etc.

Any drawback to this proposal?

I have been effected by this as well. Recently Firefox when doing middle click no longer moves the window down, which is default behavior for Ubuntu/Gnome desktop.

As a work around, I finally understand it is because the actual title bar has been hidden for Firefox windows. I like having the title bar hidden, and the tabs bar being at the top, as it gives more real estate. But middle click on the tab bar creates a new tab instead of what I expect on all apps, where middle click on the top most bar should send the window to the background.

As a work around, I found it is possible to reenable the the title bar in Firefox.

Menu->customize...

and in lower left at bottom you can check the Title Bar checkbox and you will get back the actual title bar at the top of Firefox windows. Then the middle mouse click on the real title bar sends the window to background by default as expected.

I am using this as my work around. But it would be useful to me if there was an option for the tab bar to pass the middle click to OS so it can lower window (or whatever action user has specified for middle click on title), as I would enjoy getting back the screen real estate of the title bar.

Thanks, Derek. That fixes the problem but it exposes a new bug. Now the drop shadow on the border flickers like crazy. I opened a bug in Gnome / mutter but they say that it affects XFCE as well and it's really a bug in Firefox.

https://gitlab.gnome.org/GNOME/mutter/-/issues/1514#note_952192

The relevant quote is "I see the same exact issue in xfce as well, and a quick xprop _NET_WM_OPAQUE_REGION shows Firefox sets its opaque region at (0,0) which seems wrong. considering that the the drop shadows aren't opaque of course."

(In reply to Dan Carpenter from comment #16)

Thanks, Derek. That fixes the problem but it exposes a new bug. Now the drop shadow on the border flickers like crazy. I opened a bug in Gnome / mutter but they say that it affects XFCE as well and it's really a bug in Firefox.

https://gitlab.gnome.org/GNOME/mutter/-/issues/1514#note_952192

The relevant quote is "I see the same exact issue in xfce as well, and a quick xprop _NET_WM_OPAQUE_REGION shows Firefox sets its opaque region at (0,0) which seems wrong. considering that the the drop shadows aren't opaque of course."

Please file a new bug for it against Widget:Gtk and I'll look at it. This one is about mouse button binding for titlebar.
Thanks.

Flags: needinfo?(error27)
Has Regression Range: --- → yes

I've used this workaround before but since last update OS specific clicks are not working on Title Bar anymore.

91.5.0esr (64-bit) Debian Gnome

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