HUD appears when tapping Alt+Left very quickly

Reported by Martin Pitt on 2012-03-30
270
This bug affects 47 people
Affects Status Importance Assigned to Milestone
Compiz
High
Unassigned
Compiz Core
High
Unassigned
Unity
High
Brandon Schaefer
Unity Distro Priority
High
Brandon Schaefer
compiz (Ubuntu)
High
Unassigned
unity (Ubuntu)
High
Brandon Schaefer

Bug Description

When I press Alt plus any cursor key in quick succession, the HUD erroneously appears. This steals focus and disrupts the workflow quite severely. This was much worse in earlier Unity versions, 5.8 already made this a lot better. But this case still remains for me.

When I leave some time (0.5 s or so) between pressing Alt and the cursor key, this does not happen. But when pressing them almost at the same time, the bug happens. I can reproduce this 100%, so feel free to ask for any additional debugging info.

The problem is not that I hit the Cursor key before alt. This proves it:

$ xev | grep -A2 ^KeyPress
KeyPress event, serial 36, synthetic NO, window 0x3800001,
    root 0xbe, subw 0x0, time 17590219, (112,69), root:(113,867),
    state 0x0, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
--
KeyPress event, serial 36, synthetic NO, window 0x3800001,
    root 0xbe, subw 0x0, time 17590299, (112,69), root:(113,867),
    state 0x8, keycode 113 (keysym 0xff51, Left), same_screen YES,

and I get the HUD.

It does not matter which application/window is focussed. It happens in gnome-terminal, Firefox, or the blank desktop all alike.

It does not happen with other Alt key combinations, just with the cursor keys. I also saw this happen quite a lot with Ctrl+Alt (controlling screen grab in KVM) or Ctrl+Alt+Cursor (changing workspaces), but I cannot reliably reproduce those.

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: unity 5.8.0-0ubuntu2
ProcVersionSignature: Ubuntu 3.2.0-20.33-generic 3.2.12
Uname: Linux 3.2.0-20-generic x86_64
ApportVersion: 1.95-0ubuntu1
Architecture: amd64
CompizPlugins: [core,composite,opengl,compiztoolbox,decor,vpswitch,snap,mousepoll,resize,place,move,wall,grid,regex,imgpng,session,gnomecompat,animation,fade,unitymtgrabhandles,workarounds,scale,expo,ezoom,unityshell]
Date: Fri Mar 30 12:00:47 2012
EcryptfsInUse: Yes
InstallationMedia: Ubuntu 11.10 "Oneiric Ocelot" - Beta amd64 (20110831)
ProcEnviron:
 TERM=xterm
 PATH=(custom, user)
 LANG=de_DE.UTF-8
 SHELL=/bin/bash
SourcePackage: unity
UpgradeStatus: No upgrade log present (probably fresh install)

Related branches

lp:~brandontschaefer/unity/lp.969039-move-arrow-handling-to-nux
Merged into lp:unity at revision 3544
PS Jenkins bot: Approve (continuous-integration) on 2013-09-30
Christopher Townsend: Approve on 2013-09-30
Marco Trevisan (Treviño): Needs Fixing on 2013-09-30
Martin Pitt (pitti) wrote :
Martin Pitt (pitti) wrote :

I just tried this in a guest session, and cannot reproduce it there. So I guess it's somewhat specific to my profile.

The most recent Unity upload to precise completely reset my profile to work around a bug. After that, I manually (re-)configured the following:

- Enable focus-follows-mouse in ccsm
- Bind Alt+B to "move window to background" in control-center
- Enable Launcher autohide in control-center

Sebastien Bacher (seb128) wrote :

confirmed, it happens here as well in my session:
- using standard click focus
- using alt-& ~ # etc bindings to go to ws n
- having the launcher show

so maybe it happens when alt is used in some wm bindings?

Changed in unity (Ubuntu):
status: New → Confirmed
Didier Roche (didrocks) on 2012-03-30
Changed in unity:
status: New → Confirmed
importance: Undecided → High
Changed in unity (Ubuntu):
importance: Undecided → High
tags: added: rls-p-tracking
Changed in unity-distro-priority:
status: New → Fix Committed
importance: Undecided → High
Tim Penhey (thumper) wrote :

Another edge case with tap detection.

Changed in compiz-core:
assignee: nobody → Daniel van Vugt (vanvugt)
Changed in unity:
assignee: nobody → Daniel van Vugt (vanvugt)
Changed in compiz-core:
status: New → Confirmed
Changed in compiz-core:
status: Confirmed → In Progress
Changed in unity:
status: Confirmed → In Progress
summary: - HUD appears when pressing Alt+Cursor key
+ HUD appears when tapping Alt+(some-key) very quickly

Why not just make it a different default?

Super+S would be nice, and wouldn't conflict with thirty years of software that treats modifier keys as... modifiers.

summary: - HUD appears when tapping Alt+(some-key) very quickly
+ HUD appears when tapping Alt+Left very quickly
Daniel van Vugt (vanvugt) wrote :

Martin, all, I cannot reproduce this bug. At least, not unless I press Left slightly before Alt. But that's not what you reported.

It's possible that compiz might miss the Alt+Left keypress event if it triggers a synchronous grab in another application. Synchronous means that the application briefly takes control of the X server's key event queue and could stop them from reaching the windows below, including root which is where compiz listens for the key events. This is unavoidable and unfixable, but also just a theory. I don't yet know of any application that handles Alt+Left in that way, so further details about other apps running would be helpful.

Changed in compiz-core:
status: In Progress → Incomplete
Changed in unity:
status: In Progress → Incomplete
Changed in unity (Ubuntu):
status: Confirmed → Incomplete
Martin Pitt (pitti) wrote :

I have now upgraded to the current ubuntu-desktop PPA version of compiz (1:0.9.7.4-0ubuntu1~ppa1) and I am now unable to reproduce the bug. Is it possible/plausible that this version fixed this problem? It was pretty persistent before.

Daniel van Vugt (vanvugt) wrote :

Martin, thumper found the same - broken in 0.9.7.2 and fixed in 0.9.7.4.

I am not sure of my test methodology and can't downgrade to 0.9.7.2 for a couple of hours yet to retry.

On Mon 02 Apr 2012 21:20:19 NZST, Daniel van Vugt wrote:
> Martin, thumper found the same - broken in 0.9.7.2 and fixed in 0.9.7.4.

Actually I found that I wasn't able to reproduce initially after compiz
restarted, but once it had been running for a while, I could reproduce
it again relatively easily.

Martin Pitt (pitti) wrote :

I didn't see the HUD all day yesterday, and neither today. So I cannot reproduce this with 0.9.7.4 any more, so as soon as this lands in Ubuntu the bug is fixed from my POV. Thanks!

affects: unity (Ubuntu) → compiz (Ubuntu)
Changed in compiz (Ubuntu):
status: Incomplete → Fix Committed
Didier Roche (didrocks) on 2012-04-03
Changed in compiz (Ubuntu):
status: Fix Committed → Fix Released
Changed in unity-distro-priority:
status: Fix Committed → Fix Released
Martin Pitt (pitti) wrote :

Reopening, I'm getting this again with current unity. I have not yet figured out what needs to be done to trigger the behaviour, but now that I know it wasn't magically fixed, I'll try harder. It's again 100% reproducible in my current session.

Changed in compiz (Ubuntu):
status: Fix Released → Confirmed
Daniel van Vugt (vanvugt) wrote :

Martin, could you please check xev again and verify you're not pressing Left before Alt?

Martin Pitt (pitti) wrote :

Daniel van Vugt [2012-04-11 11:27 -0000]:
> Martin, could you please check xev again and verify you're not pressing
> Left before Alt?

Yes, I already checked that.

Thomi Richards (thomir) wrote :

Happens for me too :(

Martin Pitt (pitti) on 2012-04-12
Changed in unity-distro-priority:
status: Fix Released → New
Daniel van Vugt (vanvugt) wrote :

I still can't reproduce this on a fully updated precise machine.

Martin - In Firefox, can you get the HUD to appear _and_ Firefox to register the Alt+Left/Right for backward/forward simultaneously? Or does only one of them happen?

Thomi - Same question as above. Plus, could you please run 'xev | grep -A2 Key' and attach a (complete) log of when the HUD appears erroneously?

Mark Campbell (campbemw) wrote :

Happens quite often for me when using Alt+Left and Alt+Right to change directory in nautilus. nautilus changes directory appropriately, so Alt is being pressed first; then the HUD appears. I don't see it with some other key combinations involving Alt, like Alt+Shift or Alt+Tab, that are probably handled prior to and not allowed to reach an application. I'm on 12.04 and pulled updates earlier today.

Gorka Navarrete (emrys) wrote :

Very easy to reproduce here using Nautilus, Google Chrome, etc. in a 64-bit upgrade to the final beta from 11.10.

It happens if you do ALT+left and release ALT quickly after ALT+left. If you are slow releasing ALT the problem does not occur.

Daniel van Vugt (vanvugt) wrote :

Mark, X will register Alt+Arrowkey even if the arrow key is pressed first, but only if you press Alt very soon after. That would certainly cause this bug, but the xev output in the bug description suggests that's not what's happening.

Ryan Thompson (rct86) wrote :

I can confirm that quickly pressing Alt+ left arrow will both cause firefox to go back one page and then cause the HUD to appear.

In fact, as far as I can tell, the *only* reason that this doesn't happen every single time is that if you hold down Alt too long, it times out and shows the global menu instead of activating the HUD. So basically, pressing or not pressing the arrow key makes no difference, the only thing that matters is how long you hold down Alt.

Of course, this isn't the case with most other keys. For example, Alt + Home doesn't seem show this problem.

Lars Uebernickel (larsu) wrote :

I can still reproduce this with 5.12.

Changed in compiz-core:
status: Incomplete → Triaged
Changed in unity:
status: Incomplete → Triaged
Changed in compiz-core:
status: Triaged → Confirmed
Changed in unity:
status: Triaged → Confirmed
Changed in compiz-core:
assignee: Daniel van Vugt (vanvugt) → nobody
Changed in unity:
assignee: Daniel van Vugt (vanvugt) → nobody
Changed in compiz-core:
assignee: nobody → Daniel van Vugt (vanvugt)
Changed in compiz (Ubuntu):
assignee: nobody → Daniel van Vugt (vanvugt)
Changed in unity:
assignee: nobody → Daniel van Vugt (vanvugt)
Brandon Frohs (bfrohs) wrote :

This bug affects "Back"/"Forward" keys for all ThinkPad users (both ThinkPads and ThinkPad USB Keyboard). See bug #999769.

Changed in compiz:
assignee: nobody → Daniel van Vugt (vanvugt)
status: New → Confirmed
Changed in compiz:
milestone: none → 0.9.8.0
Jan Rathmann (kaiserclaudius) wrote :

Here is a copy of the text from my duplicate bug report how to reproduce the bug with Xvkbd/Xbindkeys (with no need for the user to actually press Alt+Left/Right, I hope this may help to triage the bug):

Steps to reproduce:
1. Install Xbindkeys and Xvkbd
2. Create a .xbindkeysrc like the one attached that binds the Alt+Left/Right combos (possible needs to be altered according to the mouse being used)
3. Start Xbindkeys
4. Try to browse folders in Nautilus or web sites in Firefox.
5. Press the mouse buttons to go back and forth in folder hierarchie/web pages history.

A workaround for me is to rebind the HUD key to something different than Alt, e.g. Ctrl+Super.

Kind regards,
Jan

Daniel van Vugt (vanvugt) wrote :

Try this as a workaround (for Alt only):

System Settings > Keyboard > Shortcuts > Launchers > Key to show the HUD
Click on it and tap just the right Alt key. Now (I find) the HUD only responds to the right Alt key and will ignore the left.

Jerry Quinn (jlquinn) wrote :

I see this with both Alt-Left and Alt-Right in Firefox. The keys get delivered to Firefox and the HUD appears too.

Changed in compiz:
milestone: 0.9.8.0 → 0.9.8.1
Albert Astals Cid (aacid) wrote :

Happens on quantal too

Daniel van Vugt (vanvugt) wrote :

I have a theory...

It's possible the problem here is nautilus binding Alt+Left/Right combos on the desktop window, as it does with regular nautilus windows. If that's true, then any Alt+Left/Right eveht not completely bound to the active application will be absorbed by the nautilus desktop window. And so compiz can't receive the event (at the root window) to know that Alt was used with some other key and it thinks just Alt was tapped.

This bug affects me too in an up-to-date Precise installation. I mainly experience it when I use Alt+Up in Nautilus and it’s completely reproducable, but only when I let go of the Alt key quickly. It seems that if I let go of it before the global menu has time to show up, the HUD is shown. If the global menu has been displayed, it doesn’t show the HUD and behaves normally.

Changed in compiz:
assignee: Daniel van Vugt (vanvugt) → nobody
Changed in compiz-core:
assignee: Daniel van Vugt (vanvugt) → nobody
Changed in unity:
assignee: Daniel van Vugt (vanvugt) → nobody
Changed in compiz (Ubuntu):
assignee: Daniel van Vugt (vanvugt) → nobody
Changed in compiz:
milestone: 0.9.8.2 → 0.9.8.4
Changed in compiz:
milestone: 0.9.8.4 → 0.9.9.0
Changed in compiz:
milestone: 0.9.9.0 → 0.9.9.2
Michał Sawicz (saviq) wrote :

This bug is still valid in raring... especially visible now that you have to use alt + ← to get back in history.

Changed in compiz:
milestone: 0.9.9.2 → 0.9.10.0

I get this with my account - which I've been using for years - but it doesn't happen with a guest account. I'm using Raring.

MC Return (mc-return) wrote :

I cannot reproduce this on Raring with Compiz 0.9.10-dev and Unity trunk.
Steering Chromium history with Alt + Cursorkeys works perfectly.

@all affected:

Can you still reproduce this on Saucy ?

MC Return (mc-return) on 2013-07-24
Changed in compiz:
milestone: 0.9.10.0 → 0.9.11.0
Michał Sawicz (saviq) wrote :

Yes, I can still reproduce, alt+left, alt+right results in HUD showing up.

Changed in compiz:
importance: Undecided → High
Changed in compiz-core:
importance: Undecided → High
Changed in unity:
assignee: nobody → Brandon Schaefer (brandontschaefer)

Yay found the problem....

So. Compiz does indeed grab all the keys, which is why its hard to reproduce. The problem is for some reason in unityshell.cpp when alt tab terminates it ends up eventually doing XUngrabKey() on all the arrow keys!! So to correctly reproduce this:

1) Alt+Tab (just open the switcher and close it)
2) Attempt a alt+<arrow_key>

The offending code is here:
bool UnityScreen::altTabTerminateCommon(....)
{
  ....
  screen->removeAction(&optionGetAltTabRight ());
  screen->removeAction(&optionGetAltTabDetailStart ());
  screen->removeAction(&optionGetAltTabDetailStop ());
  screen->removeAction(&optionGetAltTabLeft ());
  ...
}

So before I push a branch i have to track down what that code is for...or what it was really fixing (don't want another regression).

It ends up ungrabbing these keycodes:

111 <- Up arrow
113 <- Left arrow
114 <- Right arrow
116 <- Down arrow

Ill attempt to get a branch out for this next week!

Changed in compiz-core:
status: Confirmed → Invalid
Changed in compiz:
status: Confirmed → Invalid
Changed in compiz (Ubuntu):
status: Confirmed → Invalid
Changed in unity (Ubuntu):
status: New → In Progress
importance: Undecided → High
assignee: nobody → Brandon Schaefer (brandontschaefer)
Changed in unity:
milestone: none → 7.1.1
status: Confirmed → In Progress
Changed in unity-distro-priority:
status: New → In Progress
status: In Progress → Confirmed

Very old code....
http://bazaar.launchpad.net/~unity-team/unity/4.0/revision/1391

Seems to be where it was introduced. (Before tap detection was ever apart of compiz).

Though this could possibly be a problem with when you remove an action, we don't re-grab all the keys...

PS Jenkins bot (ps-jenkins) wrote :

Fix committed into lp:unity at revision None, scheduled for release in unity, milestone 7.1.1

Changed in unity:
status: In Progress → Fix Committed
Changed in unity (Ubuntu):
status: In Progress → Fix Committed
Changed in unity-distro-priority:
assignee: nobody → Brandon Schaefer (brandontschaefer)
status: Confirmed → Fix Committed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package unity - 7.1.1+13.10.20131004-0ubuntu1

---------------
unity (7.1.1+13.10.20131004-0ubuntu1) saucy; urgency=low

  [ Brandon Schaefer ]
  * Break the bump detection by moving to the first icon, then down 5
    pixels. Since bump detection needs to move in 3 different
    directions.
  * Move the switcher Alt+<ArrowKey> shortcut handling into nux, from
    compiz. Now nux handles these events instead of compiz. This way its
    makes much more sense code wise and we no longer ungrab the arrow
    gets from X... so Alt+LeftArrow will no longer open the hud. (LP:
    #969039)

  [ Andrea Azzarone ]
  * Fix bad redrawing of dash overlay scrollbar connector. (LP:
    #1233195)
  * Update icon_under_mouse before process mouse movemnt in the tooltip
    manager. (LP: #1172769, #1233666)
  * Hide the tooltip when an app is closed. (LP: #1172769)

  [ Marco Trevisan (Treviño) ]
  * TestIMTextEntry: fix failing tests with IBus, use TEST_F and TEST_P.
  * CairoBaseWindow: only regenerate blur texture when visible and
    damaged. (LP: #1233109)
  * CairoBaseWindow: add fade animator to control both QL and Tooltip
    Removing the animator from LauncherIcon, and handling the tooltip
    animation inside the QL and Tooltip base class.
  * PanelService: close a menu and re-send the keyevent when handling a
    combination Or when we try to open HUD/Dash. Also, close the active
    menu if a new application is opened and focused. (LP: #10905,
    #1234457, #1197071)
  * SimpleLauncherIcon: we need to restore the focus when closing the
    Overlay for activation. (LP: #909870)
  * LauncherIcon: don't try to show again quicklists or tooltip if
    center changed, just move them. (LP: #1234778)
  * AbstractLauncherIcon: add static icon_size property. (LP: #1073103)

  [ Christopher Lee ]
  * Preparing autopilot tests for an upcoming update in autopilot 1.3.

  [ Ubuntu daily release ]
  * Automatic snapshot from revision 3554
 -- Ubuntu daily release <email address hidden> Fri, 04 Oct 2013 05:23:43 +0000

Changed in unity (Ubuntu):
status: Fix Committed → Fix Released
Miklos Juhasz (mjuhasz) wrote :

Will this fix be backported to Precise?

Stephen M. Webb (bregma) wrote :

Fix Released in Nux Unity 7.1.1.

Changed in unity:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers