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 662476 - <super> set as mouse_button_modifier seems to break gnome-shell
<super> set as mouse_button_modifier seems to break gnome-shell
Status: RESOLVED FIXED
Product: mutter
Classification: Core
Component: general
3.2.x
Other Linux
: Normal normal
: ---
Assigned To: mutter-maint
mutter-maint
: 669304 (view as bug list)
Depends on:
Blocks: 607797
 
 
Reported: 2011-10-22 20:06 UTC by Jakub Steiner
Modified: 2014-12-29 05:11 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
display: Handle overlay key overlapping with grab modifiers (1.79 KB, patch)
2011-12-13 00:36 UTC, Florian Müllner
needs-work Details | Review
display: Cancel overlay key presses on mouse button events (1.52 KB, patch)
2012-03-30 17:03 UTC, Florian Müllner
committed Details | Review

Description Jakub Steiner 2011-10-22 20:06:32 UTC
While it's not the default (and I actually believe it would be a better default, due to alt being popularly used in graphics apps) I am using <super> as the WM modifier key to resize and move windows regardles of pointer position. This worked beautifully in 3.0.

In 3.2 however, as soon as I use <super> to move or resize a window, it stops functioning as a key to bring up overview.
Comment 1 Ross Burton 2011-11-07 15:00:02 UTC
This is extra epically annoying.  Super as window modifier has always made more sense to me as I can dedicate it to window management (super-c to close, super-t for a terminal, super-arrows to switch workspaces, and now in GNOME 3 just super for the overlay).
Comment 2 Jindrich Makovicka 2011-11-20 18:21:07 UTC
Funny thing is, it starts working again after switching windows using Alt-Tab.
Comment 3 Florian Müllner 2011-12-13 00:36:03 UTC
Created attachment 203309 [details] [review]
display: Handle overlay key overlapping with grab modifiers

If the overlay key is also used as mouse button modifier, its
handling breaks after a grab operation. Detect that case and
reset overlay_key_only_pressed to fix.
Comment 4 Florian Müllner 2012-02-03 13:29:06 UTC
*** Bug 669304 has been marked as a duplicate of this bug. ***
Comment 5 Herbert Pötzl 2012-02-03 13:35:32 UTC
Note that while I agree that those Bugs are similar, I would be interested how to change the 'Grab Modifiers' (or whatever is consuming Alt-Drag at the moment) at all. I already found out how to remap the overlay_key but no luck so far with the Drag/Grab stuff
Comment 6 Florian Müllner 2012-02-03 13:38:09 UTC
gsettings set org.gnome.desktop.wm.preferences mouse-button-modifier '"<Super>"' as mentioned in the other bug (except that it doesn't work correctly due to this bug)
Comment 7 Herbert Pötzl 2012-02-03 13:44:11 UTC
thanks a bunch, works for me as the overlay key is already mapped to something else ... 
all available information pointed to the old metacity settings in gconf-editor, which obviously isn't used anymore.
Comment 8 Owen Taylor 2012-02-08 14:36:09 UTC
Review of attachment 203309 [details] [review]:

With the overlay key _not_ overlapping try pressing the super key then:

 - clicking in an application, then release super. Overlay activates
 - clicking on a gtk+ menu item, then release super. Overlay activates, menu goes into a bit of a weird state because mutter had a keyboard grab but no pointer grab
 - moving a window, then release super. Overlay key is in a broken state and doesn't open the overview, until you open the overview manaually once. (not sure why)

Should we switch the overlay key to grab mouse and pointer synchronously, and if we get a buttonp-press/release of any type, we unset overlay_key_only XAllowEvents() to reply the event and ungrab , as we do for the key case? (Since we don't have any root window grabs for the pointer, we can just let the event come back to us and hit window grabs if appropriate.)

If we did need to go something more like this patch, I'd definitely like the complex operation of determining overlay_key_modifiers not to be inlined in some random place in the code that happens to need it.
Comment 9 Florian Müllner 2012-03-30 17:03:56 UTC
Created attachment 210982 [details] [review]
display: Cancel overlay key presses on mouse button events

Currently pressing the overlay key only triggers the overview if
no other key is pressed between KeyPress and KeyRelease. Extend
this logic to pointer events, so that KeyPress + ButtonPress actions
are treated explicitly different from "pure" overlay key presses.
In particular, this change allows to re-use the overlay key as mouse
button modifier.


(In reply to comment #8)
> Should we switch the overlay key to grab mouse and pointer synchronously, and
> if we get a buttonp-press/release of any type, we unset overlay_key_only
> XAllowEvents() to reply the event and ungrab , as we do for the key case?

You mean something like


meta_grab_key():
  XGrabKey (display->xdisplay, ...,
            GrabModeSync, GrabModeSync);

event_callback():
  case ButtonPress:
  case ButtonRelease:
    display->overlay_key_only_pressed = FALSE;
    XAllowEvents (display->xdisplay, ReplayPointer, event->xbutton.time);


But doesn't a pointer_mode of GrabModeSync mean that we won't receive any pointer events until the key grab is released? I'm actually wondering whether we need a grab at all - the attached patch appears to work fine in a quick test (and doesn't mess up the mouse-button-modifier != overlay-key case) ...
Comment 10 Owen Taylor 2012-04-17 21:50:57 UTC
(In reply to comment #9)
> Created an attachment (id=210982) [details] [review]
> display: Cancel overlay key presses on mouse button events
> 
> Currently pressing the overlay key only triggers the overview if
> no other key is pressed between KeyPress and KeyRelease. Extend
> this logic to pointer events, so that KeyPress + ButtonPress actions
> are treated explicitly different from "pure" overlay key presses.
> In particular, this change allows to re-use the overlay key as mouse
> button modifier.

Tested this patch out and it seems to uniformly make things better. It doesn't fix things like the case where the modifier is <Alt> and you do:

 press <Super> 
 Click on menu in GTK+ 3 application (GTK+ 2 is OK)
 Release <Super>

But it doesn't make that worse either. I'm going to land this patch for 3.4.1 and we can consider whether we want to try something fancier for 3.6.
 
> (In reply to comment #8)
> > Should we switch the overlay key to grab mouse and pointer synchronously, and
> > if we get a buttonp-press/release of any type, we unset overlay_key_only
> > XAllowEvents() to reply the event and ungrab , as we do for the key case?

> You mean something like
> 
> meta_grab_key():
>   XGrabKey (display->xdisplay, ...,
>             GrabModeSync, GrabModeSync);
> 
> event_callback():
>   case ButtonPress:
>   case ButtonRelease:
>     display->overlay_key_only_pressed = FALSE;
>     XAllowEvents (display->xdisplay, ReplayPointer, event->xbutton.time);
>  
> But doesn't a pointer_mode of GrabModeSync mean that we won't receive any
> pointer events until the key grab is released?

You can get more events without releasing the grab using XAllowEvents- see the Xlib documentation. Don't remember offhand if you have to do one call for each motion, or you can allow events up to the next press.

> I'm actually wondering whether
> we need a grab at all - the attached patch appears to work fine in a quick test
> (and doesn't mess up the mouse-button-modifier != overlay-key case) ...

I can't think of any obvious problem with it - setting it to false won't change the behavior except that we won't trigger the overview in cases we know are problematical.

- Owen
Comment 11 Florian Müllner 2012-04-17 21:55:45 UTC
Comment on attachment 210982 [details] [review]
display: Cancel overlay key presses on mouse button events

Attachment 210982 [details] pushed as 8809673 - display: Cancel overlay key presses on mouse button events

Pushing patch, but leaving bug open in case we want something "fancier for 3.6".
Comment 12 Jasper St. Pierre (not reading bugmail) 2014-12-29 05:11:09 UTC
We've had it as the default for quite a while, so I don't think we need anything "fancier for 3.6" anymore :)