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 720545 - Timing issue with alt-key-above-tab
Timing issue with alt-key-above-tab
Status: RESOLVED FIXED
Product: mutter
Classification: Core
Component: general
3.11.x
Other Linux
: Normal normal
: ---
Assigned To: mutter-maint
mutter-maint
Depends on:
Blocks:
 
 
Reported: 2013-12-16 17:47 UTC by Adam Williamson
Modified: 2013-12-16 20:15 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
display: Fix checks for KeyPress/ButtonPress (930 bytes, patch)
2013-12-16 20:14 UTC, Owen Taylor
committed Details | Review

Description Adam Williamson 2013-12-16 17:47:45 UTC
Bit hard to explain, but let me try. I'm currently running a Fedora rawhide kernel with debugging enabled, which makes interactivity a bit slow, and it makes this issue much more obvious, though I think it always exists in theory.

It seems like there are two 'stages' to switching active windows. If I've been working in one for a while, then when I switch to another, the title bar of the new window always gets the 'I am now active!' change immediately - it stops being greyed out - but - the rest of its elements stay greyed out for a fraction of a second longer (almost imperceptible when I'm using a non-debug kernel, but noticeable when I'm using a debug one).

If I hit alt-key-above-tab during the time the new window appears to be active from its title but not from its contents, the action applies to the *old* active window, not the *new* one.

Upshot, if I have two Evolution windows and two Firefox windows and I'm trying to switch between the Evolution 'compose a message' window and both Firefox windows, I keep winding up with all the wrong windows active :/ It seems like a very corner case-y bug, but I'm actually running into it daily at the moment.

There's not a very obvious fix, I guess, since other people might be used to waiting for the other window elements to go active and would be confused if the behaviour were the other way around - maybe not everyone focuses on the window title to know when a window is active, the way I apparently do. Perhaps alt-key-above-tab behaviour could be temporarily suppressed while a window switch is between stage 1 and stage 2, or something?
Comment 1 Adam Williamson 2013-12-16 19:37:09 UTC
We did some investigation of this in #fedora-desktop , and we have what looks like a safe reproducer, at least, for F20 and F21.

Have gnome-terminal and gedit running, make sure gedit is visible behind terminal. (it's reproducible with many apps, possibly all, but this is just an example reproducer). alt-tab into gnome-terminal and run 'killall -STOP gedit'. click (don't alt-tab!) into the gedit window. wait as long as you like, note that the 'gedit is not responding' dialog doesn't come up. now hit alt-key-above-tab, and you are returned to gnome-terminal.

if you alt-tab into gedit instead of clicking into it, you will not be able to reproduce the bug, and the 'gedit is not responding' dialog will soon appear - but it never appears as long as you only click to switch to the gedit window, no matter how many times you do it or how long you wait.
Comment 2 Owen Taylor 2013-12-16 20:14:11 UTC
Created attachment 264325 [details] [review]
display: Fix checks for KeyPress/ButtonPress

Turns out that this was coincidentally fixed in master a few weeks ago, though
it's been broken for 2 years. I'm pulling this patch into the 3.10 branch.
Comment 3 Owen Taylor 2013-12-16 20:14:59 UTC
Attachment 264325 [details] pushed as 491b17a - display: Fix checks for KeyPress/ButtonPress