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 613126 - Do not cancel Alt+Tab grab due to Shift key events
Do not cancel Alt+Tab grab due to Shift key events
Status: RESOLVED FIXED
Product: mutter
Classification: Core
Component: general
git master
Other Linux
: Normal normal
: ---
Assigned To: mutter-maint
mutter-maint
Depends on:
Blocks:
 
 
Reported: 2010-03-17 10:05 UTC by Tomas Frydrych
Modified: 2010-08-23 09:37 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch not to cancel Alt+Tab grab because of Shift key press (1.13 KB, patch)
2010-03-17 10:05 UTC, Tomas Frydrych
none Details | Review

Description Tomas Frydrych 2010-03-17 10:05:20 UTC
Created attachment 156341 [details] [review]
Patch not to cancel Alt+Tab grab because of Shift key press

If the user just presses Shift during Alt+Tab grab, we need to keep the grab
in place to allow the custom Alt+Tab handler to deal with what is simply a
change of tabbing direction.
Comment 1 Dan Winship 2010-03-17 14:05:20 UTC
The shell just calls meta_keybindings_set_custom_handler() to completely intercept alt-tab processing, so we never hit any of metacity's alt-tab code. So I don't really know if this patch is right, but it won't affect us either way.
Comment 2 Tomas Frydrych 2010-03-17 14:20:26 UTC
mutter-moblin also uses meta_keybindings_set_custom_handler(). The problem is that if you press and hold the Alt+Tab combo, and then press any other key, Mutter will terminate the kbd grab an the tab_popup_cancel handler gets called. This makes sense for most keys, but not for the Shift.
Comment 3 Dan Winship 2010-03-17 14:40:09 UTC
wacky. it works fine for us.

oh, are you using meta_display_begin_grab_op/meta_display_end_grab_op to do the grab? We gave up on that and use meta_plugin_begin_modal/meta_plugin_end_modal instead. IIRC this was because we wanted to be able to use arrow keys in the Alt-Tab dialog, but metacity insisted on dropping the grab in that case, so we decided we needed to control the grab on our own so we could apply our own rules.
Comment 4 Tomas Frydrych 2010-03-17 14:45:00 UTC
Yep, using the _begin/end_grab_op; using the plugin modality might make better sense for us in the long run as well, who knows what the designers will dream of :)
Comment 5 Owen Taylor 2010-04-12 16:16:51 UTC
(In reply to comment #4)
> Yep, using the _begin/end_grab_op; using the plugin modality might make better
> sense for us in the long run as well, who knows what the designers will dream
> of :)

This seems like the better way to go to me (and if you did that, we could probably just kill the whole ability to have a "tab grab" without a tab popup), but the patch also looks harmless (if a bit hacky) so it's fine to commit if a bigger change isn't feasible at the moment.

Actually, better than this, probably you should do:

  /* don't end grab on modifier key presses */
  if (is_modifier (display, event->xkey.keycode))
    return TRUE;

Like is done in the "have a tab popup" case below, rather than hardcoding shift.
Comment 6 Owen Taylor 2010-08-16 18:02:23 UTC
Please do one or the other of:

 A) Commit the patch

 B) Mark the patch rejected and retitle this bug to "Remove ability to partially replace alt-Tab" to cover the cleanup of unused functionality.
Comment 7 Tomas Frydrych 2010-08-23 09:37:09 UTC
Pushed as commit a125b0179a0f4949ae18e905ff043e6020950c06, with the change suggested in comment 5.