GNOME Bugzilla – Bug 767967
wayland: Disabling raise-on-click cannot work on Wayland
Last modified: 2021-07-05 13:45:50 UTC
The not-to-be-changed option "raise-on-click" cannot work on Wayland because of CSD and Wayland's design that does not allow clients to manipulate the stack. So if a user ignores the lengthy explicit warning of the option description and disables "raise-on-click", this just cannot work well under Wayland (it's unlikely to work well in X11, but it's certainly won't work in Wayland). My take is that we should ignore this option under Wayland.
Created attachment 330236 [details] [review] [PATCH] wayland: ignore raise-on-click on Wayland
I suppose the only way one could otherwise raise the window is by using Alt-Tab.
Note, we /could/ wire up the gtk header bar with the gtk-shell present protocol so that when the user clicks on the header bar in CSD/Wayland, the window is raised/focused.
(In reply to Olivier Fourdan from comment #3) > Note, we /could/ wire up the gtk header bar with the gtk-shell present > protocol so that when the user clicks on the header bar in CSD/Wayland, the > window is raised/focused. Seems funky. Either we'd need to make gtk+ peek into mutters settings, or always ask call present, which doesn't make much sense to me.
Just as a note, after spending some time working on the opposite problem on Chromium (windows raise when they shouldn't), I can assert there are dozens of us who care about this working correctly. :) https://bugs.chromium.org/p/chromium/issues/detail?id=318937
I think it makes most sense to simply let it be, and make disabled raise-to-click continue to do nothing on Wayland. If the user really wants to raise, then Super-click, or alt-tab to it. We could maybe update the text in the schema though to say "clicking within the frame" will not work on Wayland.
I will need to study Wayland a bit to understand this better, but could mutter be given information about what regions should react to clicks for raising? Also, if Wayland clients cannot choose to raise themselves, how do Xwayland clients work properly here?
(In reply to Adam Goode from comment #7) > I will need to study Wayland a bit to understand this better, but could > mutter be given information about what regions should react to clicks for > raising? You could, but you'd probably need a protocol addition (most likely in xdg-shell) > Also, if Wayland clients cannot choose to raise themselves, how do Xwayland > clients work properly here? Does it work with "GTK_CSD=1 GDK_BACKEND=x11 gtk3-demo" for example? I think it might depend between CSD and SSD clients here, with SSD, mutter still draws the decorations and title bar and therefore can raise the window when the user clicks on those.
IMO we don't need to change anything here. If anything, I'd rather we remove the option and make raise-on-click mandatory.
(In reply to Rui Matos from comment #9) > IMO we don't need to change anything here. If anything, I'd rather we remove > the option and make raise-on-click mandatory. That's my opinion as well, that's what attachment 330236 [details] [review] is meant to do (for Wayland only)
(In reply to Adam Goode from comment #7) > Also, if Wayland clients cannot choose to raise themselves, how do Xwayland > clients work properly here? Mutter raises them. We install an X button grab on all unfocused windows to ensure we get button events on them so we can raise, focus, etc.
Requiring raise-on-click would be a significant X-to-Wayland regression. I am in favor of removing the functionality now if it is broken, but hope that patches to reimplement it properly (as a wayland protocol?) would be accepted in the future.
(In reply to Adam Goode from comment #12) > I am in favor of removing the functionality now if it is broken, but hope > that patches to reimplement it properly (as a wayland protocol?) would be > accepted in the future. I'm missing some crucial bit here. What's broken? mutter's preference raise-on-click, both set to true and false, works just fine on wayland and X sessions AFAICT.
raise-on-click=true is the default and has an obvious implementation: raise whenever a click lands in the window. raise-on-click=false means "don't raise, unless the click is on a special window-specific part of the window". It's more complex, since it is not "never raise". With server-side decorations, this is simple since the special part of the window is the server-side drawn part, which is easy to detect. With client-side decorations, the client must either raise the window itself (which it cannot in Wayland?), or tell something else to raise it. This is the part that does not work in Wayland. This was a problem in regular X with CSD long ago and was fixed in https://git.gnome.org/browse/gtk+/commit/?id=ac497c6e8f45bfece4054ba7f72ffd7becb45311
See https://git.gnome.org/browse/gtk+/tree/gdk/wayland/gdkwindow-wayland.c#n1906 for why this doesn't work anymore.
I have not tried it, but does middle-click to lower also not work in GNOME on Wayland? My guess is no. https://git.gnome.org/browse/gtk+/tree/gtk/gtkwindow.c#n1367 lower is also now implemented...
s/now implemented/not implemented/
(In reply to Olivier Fourdan from comment #3) > Note, we /could/ wire up the gtk header bar with the gtk-shell present > protocol so that when the user clicks on the header bar in CSD/Wayland, the > window is raised/focused. Another option to make it work would be to allow clients to communicate the frame borders to the compositor (say: set_frame_borders()). This would allow us to figure out whether an event happened on the titlebar/frame for CSD windows (including wayland) without giving clients any direct control over the stack.
(In reply to Adam Goode from comment #15) > See > https://git.gnome.org/browse/gtk+/tree/gdk/wayland/gdkwindow-wayland.c#n1906 > for why this doesn't work anymore. No, the reason is Wayland not letting clients manipulate the stack, therefore a client raise is necessarily a no-op in the toolkit (i.e. the line you point out is the effect, not the cause).
(In reply to Adam Goode from comment #14) > raise-on-click=false means "don't raise, unless the click is on a special > window-specific part of the window". It's more complex, since it is not > "never raise". Interesting, I wasn't aware of this definition. I wonder how widespread that definition is... In any case, strictly from mutter's POV, the option does exactly what it says it does, both under X and under wayland, so I suppose this bug should be re-purposed to discuss "how can wayland clients raise their surfaces" ?
(In reply to Rui Matos from comment #20) > In any case, strictly from mutter's POV, the option does exactly what it > says it does, both under X and under wayland, so I suppose this bug should > be re-purposed to discuss "how can wayland clients raise their surfaces" ? Yes, that is a better formulation of the problem. From what I've gathered, Wayland started with a clean slate and subsequent design and development has carefully considered which features to implement and how. This is an excellent approach in avoiding duplicating misfeatures of previous systems. On this bug, I've noticed apprehension about having raise/lower be supported in Wayland. I think we can come up with a design that satisfies the needs of current window management practices while avoiding the issues that come up with direct client controlled stacking.
Can the bug be renamed? I don't have the option to do so.
Also, I have confirmed that this setting no longer works: /org/gnome/desktop/wm/preferences/action-middle-click-titlebar: 'lower' This is settable from the Gnome Tweaks tool, or in dconf. It is the same issue: keyboard shortcuts to raise or lower are fine, but CSD-activated actions do not.
I doubt my two cents count for much, but I oppose mandatory raise-on-click. It concerns me that such optional behavior could be made impossible for all window managers. If a particular desktop doesn't have the option, fine, but it should be possible to implement either behavior, somehow. I've always used do-not-raise-on-click, never not used it. It was the second X11 feature that I fell in love with, after follow-focus. And, I always understood it to mean what Goode described in comment #14. Regarding comment #23, that's what I was looking to report and I think I will start a new bug for that as that has been a problem outside of Wayland for several years now.
Ah, woops, this bug only applies to mutter. Thought it was for all GNOME3 applications. My mistake, sorry, disregard.
Regarding comment 23, this makes using auto-raise impossible. I stopped using click-to-focus in 1993 and click-to-focus was one reason why I removed Windows 3.1 and first installed Slackware 2.0 in 1994. I've been an auto-raise user for 22 1/2 years. The idea with auto-raise is that you can work much more efficiently. You move your mouse to the window where you want to work and you can begin typing within generally 300-500 milliseconds. With today's snappy graphics, CPU and mouse/touch pad hardware you can comfortably reduce the auto-raise delay to 100 milliseconds. The setting action-middle-click-titlebar lower is required when any window on the desktop is hiding the window you need to interact with. Auto-raise can't help you in this situation. For about a decade I've had about 9 or 10 gnome-terminals active on my main screen at all times. GNOME 2.x I think added the functionality where you can move your mouse to the upper left and then click on the window you want using a reduced-sized representation, but unfortunately that UI was not well thought out when you have 9 or 10 gnome-terminals that look nearly identical. This UI only works well when you are working with a diverse set of windows. I never do that. Having some sort of interaction to lower windows is required for auto-raise usability. Personally I don't care whether it's a mouse click or even a double click, or which mouse button, but in order for auto-raise to work the functionality is required. The middle mouse button seems to work well.
I plan to introduce 'raise' and 'lower' to xdg-shell, in wayland-protocols. If that is accepted, then adding the support to the rest of the stack should be straightforward.
The recommendation on wayland-discuss is to infer interaction with client-side decorations by way of the xdg-shell move and resize commands. https://lists.freedesktop.org/archives/wayland-devel/2016-November/032021.html This would let us treat the titlebar and resize frame as we did in the non-CSD case. Mutter would react to different button presses (and double click) based on the bindings. There is already code for all this for non-CSD, it just needs to be hooked up to move and resize for xdg-shell. I will try to figure out a patch.
There is more discussion on the wayland-devel thread. There is no conclusion yet.
I have a proposal for xdg-shell to enable this functionality. See https://patchwork.freedesktop.org/series/16642/ https://patchwork.freedesktop.org/series/17007/ https://lists.freedesktop.org/archives/wayland-devel/2016-December/032361.html Comments/reviews welcome on the wayland list.
Not being able to disable raise-on-click was a large and unnecessary hindrance, but I gradually got used to it. I hope I don't have to permanently get used to the large and unnecessary hindrance of not being able to lower windows too. I'm really frustrated by this obsession for stripping away convenient ways to work with multiple windows. BTW, Chrome can still lower on middle click in Wayland. I suppose that's something to do with its still using an X11 back-end, but it is CSD, and the clicks are context-sensitive, so it's strange that GTK3 can't do it.
Chrome can do it because XWayland will honor raise and lower requests from clients. I have been thinking of another protocol proposal to address this limitation (the previous one had some problems), but haven't had time to write it up yet. Hopefully in a few weeks.
(In reply to Adam Goode from comment #32) > Chrome can do it because XWayland will honor raise and lower requests from > clients. I thought it must have something to with X11, but I still don't understand how it's possible for XWayland to let CSD windows lower themselves when it isn't possible for GTK3. > I have been thinking of another protocol proposal to address this limitation > (the previous one had some problems), but haven't had time to write it up > yet. Hopefully in a few weeks. This is encouraging. I did see your messages on the XDG mailing list, but I posted here instead because I thought there might be a way around it in GTK3/gnome-shell and, TBH, also because it's much easier to use my existing account here than to sign up to a mailing list. I do hope you're an official developer or otherwise have enough influence that they'll incorporate your proposal in the not too distant future. Is there something else I can do to indicate demand for this feature? (I will join the mailing list if that would help :-)).
No, I've never contributed to Wayland before. I did get good feedback on the list from my older proposal. I think it helped that I got some of it prototyped in Weston as well. It doesn't hurt to join the mailing list, but there is a lot of mail there.
Hey, has there been any progress on this issue since the last post? Middle-click to lower is one of my favorite window gestures, and it's a shame that only XWayland clients support it properly. Was a protocol extension proposal submitted to Wayland for native raise/lower support?
No, I proposed some suggestions on the mailing list, but my proposals had serious issues that I've not addressed yet, and I haven't worked on this since then. (I just switched back to X11 for now.) My next idea (that I haven't prototyped yet) is that clients should be able to tell the server which parts of the window are decorations. Then the server can interpret middle-click on a decorated part like X11 used to do with server-side decorations. No idea if that will work, but that's the state of things.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/mutter/-/issues/ Thank you for your understanding and your help.