After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 746642 - Shift/ctrl/alt + click on non-main window don't change focus
Shift/ctrl/alt + click on non-main window don't change focus
Status: RESOLVED FIXED
Product: mutter
Classification: Core
Component: general
3.14.x
Other Linux
: Normal normal
: ---
Assigned To: mutter-maint
mutter-maint
Depends on:
Blocks:
 
 
Reported: 2015-03-23 13:13 UTC by Javier Domingo
Modified: 2016-11-24 07:16 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
keybindings: Grab buttons with any modifier combo on unfocused windows (2.03 KB, patch)
2016-02-10 14:44 UTC, Rui Matos
none Details | Review
keybindings: Factor out a function to determine XIGrabModifiers (5.94 KB, patch)
2016-02-10 19:55 UTC, Rui Matos
committed Details | Review
keybindings: Grab buttons with any modifier combo on unfocused windows (2.80 KB, patch)
2016-02-10 20:00 UTC, Rui Matos
committed Details | Review
keybindings: Remove #if 0'd code (2.39 KB, patch)
2016-11-21 15:47 UTC, Rui Matos
committed Details | Review

Description Javier Domingo 2015-03-23 13:13:06 UTC
If in a window (in my case usually chrome is the main window), using one modifier (ctrl/alt/shift) + click on another window won't change the window focus, but will do intended action.

For example, having main focus on chrome, if shift+drag on the console, it will select what intended, however, when pressing ctrl+shift+c to copy from the terminal will spawn the Developer Tools from chrome instead of copying from the shell because the focus will still be on the Chrome window instead of the Terminal.
Comment 1 Javier Domingo 2015-03-23 13:15:16 UTC
BTW, Super key works as intended (drags the window)
Comment 2 Rui Matos 2015-03-23 13:28:28 UTC
Not 100% sure but I think this was the behavior even in metacity, so it's arguable that it's a bug
Comment 3 Javier Domingo 2015-03-23 14:09:31 UTC
I would say it's a bug because it doesn't make sense to not be able to do any action on the window, and the window not being selected. Just as Super+click(hold) changes, the rest should do the same.

I have noticed it in last few months, can't say if before, but ...
Comment 4 Rui Matos 2016-02-10 14:44:58 UTC
Created attachment 320803 [details] [review]
keybindings: Grab buttons with any modifier combo on unfocused windows

We currently only focus unfocused windows on button press if no
modifiers (or just ignored modifiers) are in effect. This behavior
seems surprising and counter-intuitive so let's do it for any modifier
combination instead.
Comment 5 Rui Matos 2016-02-10 19:55:59 UTC
Created attachment 320825 [details] [review]
keybindings: Factor out a function to determine XIGrabModifiers

This de-dups code and reduces the amount of protocol round trips.
Comment 6 Rui Matos 2016-02-10 20:00:19 UTC
Created attachment 320827 [details] [review]
keybindings: Grab buttons with any modifier combo on unfocused windows

We currently only focus unfocused windows on button press if no
modifiers (or just ignored modifiers) are in effect. This behavior
seems surprising and counter-intuitive so let's do it for any modifier
combination instead.
--

There was a bug in the previous version because ungrabbing with
XIAnyModifier undoes all grabs for a button but we still want to keep
the window buttons grab (e.g. super+click+drag to move) working on
focused windows.

Also tested this with !click focus modes and it works fine.
Comment 7 Rui Matos 2016-03-14 17:59:15 UTC
Can I get a review for these?
Comment 8 Rui Matos 2016-08-29 15:42:56 UTC
Ping? The first patch at least is a nice cleanup IMO
Comment 9 Jonas Ådahl 2016-11-21 04:00:48 UTC
Review of attachment 320825 [details] [review]:

Looks good to me.
Comment 10 Jonas Ådahl 2016-11-21 04:17:12 UTC
Review of attachment 320827 [details] [review]:

Disclaimer: by far not an X11 expert

This looks reasonable to me, i.e. when the window is not focused and the mode is click-to-focus, it makes no sense to grab clicks but not to grab mod+clicks. My only concern changing the preference; it looks like we'll always bind every window as if it would be unfocused (looking at "prefs_changed_callback()"). That said it's not clear to me how it worked before this either.
Comment 11 Rui Matos 2016-11-21 15:47:20 UTC
Created attachment 340435 [details] [review]
keybindings: Remove #if 0'd code

There's no reason to keep this ~15 year old piece of code around as
well as the preference handling that would only make sense if this
hunk was actually enabled.

--

Do you mean this pointless bit in display.c:prefs_changed_callback() ?
Comment 12 Rui Matos 2016-11-21 15:52:21 UTC
(In reply to Jonas Ådahl from comment #10)
> My only concern changing the preference; it looks like we'll
> always bind every window as if it would be unfocused (looking at
> "prefs_changed_callback()"). That said it's not clear to me how it worked
> before this either.

Or do you mean the meta_display_ungrab/grab_window_buttons in keybindings.c:prefs_changed_callback() ? If this is the one you mean, note that this is unrelated to the unfocused window button grab that this bug is about and seems correct to me: we always keep the special button+button_modifier_pref combo grabbed for things like mod+button1 to move windows, mod+button2 to resize, etc.
Comment 13 Rui Matos 2016-11-21 15:56:09 UTC
Comment on attachment 320825 [details] [review]
keybindings: Factor out a function to determine XIGrabModifiers

Attachment 320825 [details] pushed as d829fa1 - keybindings: Factor out a function to determine XIGrabModifiers
Comment 14 Florian Müllner 2016-11-21 16:18:02 UTC
Review of attachment 340435 [details] [review]:

Yeah, makes sense to me

::: src/core/keybindings.c
@@ -1063,3 @@
 
-#if 0
-  /* FIXME:115072 */

While at it, should remove the "in click-to-focus mode" bit from the comment above the function
Comment 15 Rui Matos 2016-11-23 18:00:16 UTC
Attachment 320827 [details] pushed as 2b59b4c - keybindings: Grab buttons with any modifier combo on unfocused windows
Attachment 340435 [details] pushed as 0249993 - keybindings: Remove #if 0'd code
Comment 16 Jonas Ådahl 2016-11-24 07:16:12 UTC
(In reply to Rui Matos from comment #12)
> (In reply to Jonas Ådahl from comment #10)
> > My only concern changing the preference; it looks like we'll
> > always bind every window as if it would be unfocused (looking at
> > "prefs_changed_callback()"). That said it's not clear to me how it worked
> > before this either.
> 
> Or do you mean the meta_display_ungrab/grab_window_buttons in
> keybindings.c:prefs_changed_callback() ? If this is the one you mean, note
> that this is unrelated to the unfocused window button grab that this bug is
> about and seems correct to me: we always keep the special
> button+button_modifier_pref combo grabbed for things like mod+button1 to
> move windows, mod+button2 to resize, etc.

This. I think I understand whats going on now. My concern (or rather, the thing I didn't completely grasp) was whether we took the grab correctly when changing the preference, but indeed can't see anything wrong.