Closed Bug 1539998 Opened 5 years ago Closed 3 months ago

Titlebar mouse clicks do not follow Gnome titlebar actions

Categories

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

66 Branch
defect

Tracking

()

RESOLVED FIXED
124 Branch
Tracking Status
firefox-esr60 --- wontfix
firefox-esr115 --- wontfix
firefox66 --- wontfix
firefox67 --- wontfix
firefox68 --- wontfix
firefox122 --- wontfix
firefox123 --- wontfix
firefox124 --- fixed

People

(Reporter: frank.bruetting, Assigned: stransky)

References

(Blocks 1 open bug, Regression)

Details

(Keywords: regression)

Attachments

(7 files, 4 obsolete files)

95.30 KB, image/png
Details
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review
48 bytes, text/x-phabricator-request
Details | Review

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)
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.

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

Severity: normal → S3

Hi.

Unless you're planning to do something really useful with the middle button other than the same thing you can achieve clicking the [ + ] button (new tab) at the "top bar" or using the the Ctrl+t shortcut, I would recommend to just pass the event to the parent.

For me this action is really useful given that I've it linked to -Lower- which is an action provided by Gnome (desktop environment) that puts the window behind. I don't need to switch workspaces, nor use keyboard shortcuts to change focus.

Considering that when I use the browser I usually have one of my hands in the mouse. The only excuse I would have for the need of a fast/handy new-tab-shortcut linked to the middle-mouse-button would be "to hide" rapidly the content I'm looking at. That is not the case, I insist, it would be much more valuable (and better for my freedom) if you give me back control of the window and let me decide how windows (in general) should behave.
This means, I don't want to search hundreds of properties at about:config. Let alone having to create an account to make a comment (almost a complain) about what is expected from a browser created by a huge community of people with common sense. Please just don't hide what is what, that is not the top bar of the window, it's the one of the browser (the app), it is Firefox's top bar. I understand that having the top bar of the window will do it ugly, but it is mine. This is not a bug it's a takeover of functionality.

We could agree about how useless the top bar of the window is, sure. But I don't think it is right to override an expected behavior unless I agree to do it, like in settings or installing some extension that change the properties/behavior of the window. Historically windows have been boring (that explains the Themes section) but think about the future.

Thank you for the amazing work here and the mobile version

I think we can add pref to enable Gnome button actions on the titlebar. But we need to read it first from the preference and then apply the action.
The code may be pretty straightforward.

We use something similar to PIP windows:
https://searchfox.org/mozilla-central/rev/a5da23c8c9c1151dcdf0ca34b3cfd0a4d0fc3b48/widget/gtk/nsWindow.cpp#4788

So we should add the action according to Gnome settings here:
https://searchfox.org/mozilla-central/rev/a5da23c8c9c1151dcdf0ca34b3cfd0a4d0fc3b48/widget/gtk/nsWindow.cpp#4707

if we get user click in mDraggableRegion and middle button is pressed.

Anyone want to step in and make a patch?

Type: enhancement → defect
Flags: needinfo?(stransky)

Thank you for sharing those snippets Martin and for welcome the suggestion. I wanted to take a look at the code so thank you very much, honestly.

I'm resolving some issues related to bootstrap tools so this patch wont come from me unless I solve them.
Although something that has crossed my mind and worth to mention is, the top bar could also be considered useful for pen displays / pen tablets

Redirect a needinfo that is pending on an inactive user to the triage owner.
:stransky, since the bug has recent activity, could you please find another way to get the information or close the bug as INCOMPLETE if it is not actionable?

For more information, please visit BugBot documentation.

Flags: needinfo?(error27) → needinfo?(stransky)
Flags: needinfo?(stransky)
Flags: needinfo?(stransky)
Flags: needinfo?(stransky)
Flags: needinfo?(stransky)
Assignee: nobody → stransky
Status: NEW → ASSIGNED
Type: enhancement → defect
Flags: needinfo?(stransky)
Priority: P5 → P3
Type: enhancement → defect
Attachment #9376198 - Attachment is obsolete: true
Attachment #9376199 - Attachment is obsolete: true
Attachment #9376200 - Attachment is obsolete: true
Attachment #9376201 - Attachment is obsolete: true

widget.gtk.titlebar-action-middle-click-enabled overrides Firefox default titlebar action (open new tab).

Get titlebar actions from gtk-titlebar-double-click / gtk-titlebar-middle-click gsettings keys and monitor key changes and export it as nsLookAndFeel::GetTitlebarAction().

Depends on D199881

Attachment #9376968 - Attachment description: Bug 1539998 [Linux] Ship widget.gtk.titlebar-action-middle-click-enabled pref r?emilio → Bug 1539998 [Linux] Create widget.gtk.titlebar-action-middle-click-enabled pref r?emilio
Pushed by stransky@redhat.com:
https://hg.mozilla.org/integration/autoland/rev/530a063dda09
[Linux] Create widget.gtk.titlebar-action-middle-click-enabled pref r=emilio
https://hg.mozilla.org/integration/autoland/rev/845f7432bc17
[Linux] Don't open new tab if widget.gtk.titlebar-action-middle-click-enabled is set r=emilio,tabbrowser-reviewers,mconley
https://hg.mozilla.org/integration/autoland/rev/0262a031a823
[Linux] Implement nsLookAndFeel::GetTitlebarAction() r=emilio
https://hg.mozilla.org/integration/autoland/rev/c993e509f8ce
[Linux] Implement nsWindow::DoTitlebarAction() r=emilio
https://hg.mozilla.org/integration/autoland/rev/fbbba64778b2
[Linux] Perform titlebar action for double click r=emilio
https://hg.mozilla.org/integration/autoland/rev/381f7d17a53e
[Linux] Perform titlebar action for middle click r=emilio
Regressions: 1877618
Blocks: 1877819
Regressions: 1878029

We may consider to enable it by default for GNOME desktop.

Flags: needinfo?(stransky)
See Also: → 1439247
Flags: needinfo?(stransky)

Created a blogpost about this change, I forgot to add it to release notes.
https://mastransky.wordpress.com/2024/03/19/firefox-124-supports-gnome-titlebar-actions/

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

Attachment

General

Creator:
Created:
Updated:
Size: