meta/alt-(key) combos intercepted by HUD *and* applications

[Reece]

I'm a long-time Unity user. After recently upgrading to 14.04, I notice that Meta/Alt is intercepted by Unity to expose the HUD *even when in a key combination*.

For example, within emacs and gnome-terminal (readline), I used to be able to use Alt-D do forward delete a word. With 14.04, Alt-D deletes a word and brings up HUD. (This is particularly annoying because the window loses focus and my next bit of typing ends up in the search bar.)

I am certain that this wasn't an issue in previous releases.

[Mateusz Stachowski (stachowski-mateusz)]

@Reece this happens only if you press the keys at the same time. If for example in Terminal you first press Alt and the D and release the keys the forward word gets deleted without opening HUD.

I've seen similar bug reports where pressing the keys at the same moment will trigger one of Unity actions but pressing them separately would work as expected.

[Reece (reece)]

@Mateusz I can't tell whether you're agreeing or not. Your second sentence ("If for example...") is not generally true for me. I am quite confident that 14.04 is subtly different from 13.10 in the timing and sequencing criteria for Alt and Alt-key discrimination.

The best demonstration of this is to consciously hold Alt then hit D (or any other key). If I do this slowly, HUD does not appear (that is, works as expected). If I do this quickly while being careful to maintain Alt-then-key ordering, HUD appears as described. The same behavior occurs for B (backward-word) and F (forward-word), etc.

In fact, HUD appears only with short Alt keydown-up events; it does not appear with long Alt keypresses. This is irrespective of another key event.

So, in my case, a fast Alt-anything brings up HUD whereas a slow Alt-anything doesn't because Alt his held briefly in the first case and longer in the second.

[Brandon Schaefer (brandontschaefer)]

I cant reproduce, but to double check could you use xev to ensure alt is down first? If you do d + alt, the hud will come up.

A work around is to change the hot key for hud to something other then alt as well in ccsm.

[Reece (reece)]

Thanks for trying to verify. Below are xev KeyPress and KeyRelease sequences for cases where HUD did and did not appear.

Since I've been using ubuntu/compiz/unity for a while, it seemed possible that I have some old config kruft that was necessary for this bug. I started up a guest session and indeed the problem does not appear.

So, my current hypothesis is that there is a user selectable delay buried somewhere that I configured long ago in a galaxy far far away. Any ideas where to look for that? Or, barring that, what config file to toss as a test?

xev data:
=======

Here's an xev sequence that caused the hud to appear.

KeyPress event, serial 28, synthetic NO, window 0x5400001,
    root 0x9f, subw 0x0, time 134674304, (69,151), root:(1141,203),
    state 0x0, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 28, synthetic NO, window 0x5400001,
    root 0x9f, subw 0x0, time 134674384, (69,151), root:(1141,203),
    state 0x8, keycode 40 (keysym 0x64, d), same_screen YES,
    XLookupString gives 1 bytes: (64) "d"
    XmbLookupString gives 1 bytes: (64) "d"
    XFilterEvent returns: False

KeyRelease event, serial 28, synthetic NO, window 0x5400001,
    root 0x9f, subw 0x0, time 134674424, (69,151), root:(1141,203),
    state 0x8, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyRelease event, serial 28, synthetic NO, window 0x5400001,
    root 0x9f, subw 0x0, time 134674442, (69,151), root:(1141,203),
    state 0x0, keycode 40 (keysym 0x64, d), same_screen YES,
    XLookupString gives 1 bytes: (64) "d"
    XFilterEvent returns: False

And, for comparison, a sequence that didn't cause hud:

KeyPress event, serial 28, synthetic NO, window 0x5400001,
    root 0x9f, subw 0x5400002, time 134756538, (33,44), root:(1728,1283),
    state 0x0, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 28, synthetic NO, window 0x5400001,
    root 0x9f, subw 0x5400002, time 134756956, (33,44), root:(1728,1283),
    state 0x8, keycode 40 (keysym 0x64, d), same_screen YES,
    XLookupString gives 1 bytes: (64) "d"
    XmbLookupString gives 1 bytes: (64) "d"
    XFilterEvent returns: False

KeyRelease event, serial 28, synthetic NO, window 0x5400001,
    root 0x9f, subw 0x5400002, time 134757034, (33,44), root:(1728,1283),
    state 0x8, keycode 40 (keysym 0x64, d), same_screen YES,
    XLookupString gives 1 bytes: (64) "d"
    XFilterEvent returns: False

KeyRelease event, serial 28, synthetic NO, window 0x5400001,
    root 0x9f, subw 0x5400002, time 134757134, (33,44), root:(1728,1283),
    state 0x8, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Alex Baggott (alex-baggott)]

This seems to be fixed in 15.10.