Titlebar mouse clicks do not follow Gnome titlebar actions
Categories
(Core :: Widget: Gtk, defect, P3)
Tracking
()
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.
Updated•6 years ago
|
Comment 1•6 years ago
|
||
(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.
- Can you explain how exactly you did that with detailed steps?
- Which version of Fedora are you using?
Thank you for your contribution!
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…
Comment 3•6 years ago
|
||
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!
Updated•6 years ago
|
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!
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Comment 6•5 years ago
|
||
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.
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.
Comment 8•5 years ago
|
||
(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?
Comment 10•5 years ago
|
||
So why do you expect title bar settings to affect the area next to the address bar?
Reporter | ||
Comment 11•5 years ago
|
||
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.
Comment 13•5 years ago
|
||
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.
Updated•5 years ago
|
Comment 14•5 years ago
|
||
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?
Assignee | ||
Updated•5 years ago
|
Comment 15•4 years ago
|
||
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.
Updated•4 years ago
|
Comment 16•4 years ago
|
||
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."
Assignee | ||
Comment 17•4 years ago
|
||
(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.
Updated•3 years ago
|
Comment 18•3 years ago
|
||
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
Updated•2 years ago
|
Comment 19•1 year ago
|
||
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
Assignee | ||
Comment 20•1 year ago
|
||
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?
Assignee | ||
Updated•1 year ago
|
Comment 21•1 year ago
|
||
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.
Comment 22•1 year ago
|
||
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
Comment 23•1 year ago
|
||
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.
Assignee | ||
Updated•1 year ago
|
Assignee | ||
Updated•1 year ago
|
Assignee | ||
Updated•1 year ago
|
Assignee | ||
Updated•10 months ago
|
Assignee | ||
Comment 24•8 months ago
|
||
Updated•8 months ago
|
Assignee | ||
Comment 25•8 months ago
|
||
Depends on D199479
Assignee | ||
Comment 26•8 months ago
|
||
Depends on D199480
Assignee | ||
Comment 27•8 months ago
|
||
Depends on D199481
Assignee | ||
Updated•8 months ago
|
Assignee | ||
Updated•8 months ago
|
Updated•8 months ago
|
Updated•8 months ago
|
Updated•8 months ago
|
Updated•8 months ago
|
Assignee | ||
Comment 28•8 months ago
|
||
widget.gtk.titlebar-action-middle-click-enabled overrides Firefox default titlebar action (open new tab).
Assignee | ||
Comment 29•8 months ago
|
||
Depends on D199880
Assignee | ||
Comment 30•8 months ago
|
||
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
Assignee | ||
Comment 31•8 months ago
|
||
Depends on D199882
Assignee | ||
Comment 32•8 months ago
|
||
Depends on D199883
Assignee | ||
Comment 33•8 months ago
|
||
Depends on D199884
Updated•8 months ago
|
Comment 34•8 months ago
|
||
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
Comment 35•8 months ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/530a063dda09
https://hg.mozilla.org/mozilla-central/rev/845f7432bc17
https://hg.mozilla.org/mozilla-central/rev/0262a031a823
https://hg.mozilla.org/mozilla-central/rev/c993e509f8ce
https://hg.mozilla.org/mozilla-central/rev/fbbba64778b2
https://hg.mozilla.org/mozilla-central/rev/381f7d17a53e
Updated•7 months ago
|
Assignee | ||
Comment 36•7 months ago
|
||
We may consider to enable it by default for GNOME desktop.
Assignee | ||
Updated•6 months ago
|
Assignee | ||
Comment 37•6 months ago
|
||
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/
Description
•