GNOME Bugzilla – Bug 756789
Grabbing something unfocused with SUPER+Left-click does not focus it
Last modified: 2016-01-05 19:46:07 UTC
Created attachment 313628 [details] screencast of grabbing an unfocused window without it receiving focus If I grab a window which dont have focus and I do so with SUPER+Left-click, it is moved to top level but doesnt receive focus afterwards. Attached video demonstrates. I am using mutter 3.18.1 under Wayland 1.9.0.
*** Bug 756790 has been marked as a duplicate of this bug. ***
Created attachment 313762 [details] [review] ui/frames: Don't focus if the button press is on the client area This is a really old behavior introduced in commit 585e3625266dd0fadcdb033739760db423d31714 which is inconsistent since it only applies to SSD windows. If we really want this, we should focus the window elsewhere so that it applies consistently to all windows. -- Now, do we want to focus all windows in this case?
Does the frames code even get it? I thought we'd get the grab early and eat the event once we went into grab mode. I always thought it was intentional behavior that moving a window doesn't focus it. Seems like kind of useful behavior to me, actually.
(In reply to Jasper St. Pierre from comment #3) > Does the frames code even get it?
+ Trace 235599
Ah, right, I made it call meta_frames_handle_event first thing in https://git.gnome.org/browse/mutter/tree/src/core/window.c#n7673 I'm actually not sure that's 100% right, because it means Super+Left Clicking on a button will activate the button. I definitely remember a bug about who should take precedence between two incompatible operations. But still, we should decide on a behavior and implement it in all cases. Let's go for focusing -- your patch looks fine to me.
Review of attachment 313762 [details] [review]: OK.
Created attachment 313821 [details] [review] window: Remove a spurious meta_verbose() This was duplicated here by mistake in the big re-work commit 7a109a18affe6de25ade043e72f8bc3da739f233 .
Created attachment 313822 [details] [review] window: Focus windows on button press regardless of modifier state This seems like a more generally useful and intuitive behavior. -- (In reply to Jasper St. Pierre from comment #5) > But still, we should decide on a behavior and implement it in all > cases. Let's go for focusing This should do it. Also, while looking at it again, I found out that in X sessions this wasn't a problem at all because _begin_grab_op() calls meta_window_grab_all_keys() which, on X11, does meta_window_focus().
Created attachment 313823 [details] [review] window: Focus windows on button press regardless of modifier state This seems like a more generally useful and intuitive behavior. Note that, in X sessions, this is what already happened in practice since meta_display_begin_grab_op() calls meta_window_grab_all_keys() which, on X11, does meta_window_focus(). -- forgot to update the commit message to reflect what I had found
Review of attachment 313821 [details] [review]: sure.
Review of attachment 313823 [details] [review]: Works for me.
Attachment 313762 [details] pushed as e0906a7 - ui/frames: Don't focus if the button press is on the client area Attachment 313821 [details] pushed as 8e22dce - window: Remove a spurious meta_verbose() Attachment 313823 [details] pushed as 88acfb8 - window: Focus windows on button press regardless of modifier state