Keyboard shortcuts, window management - Can't use any global keyboard shortcuts or hotkeys when applet/menu is open

I think that's a known issue, happens with all the menu not only the panel ones.
Probably a WONTFIX, because the shortcut can be useful in the menu and conflicting
with the environment

closing as NOTABUG, that's a design choice and not a bug. Feel free to reopen if
you disagree

Right. So no hotkeys or function keys work when a menu or applet is down and it is a design choice. I personally don't think that leaving it at that is really the optimal solution.

I can't think of any of the hotkeys in question being used in the menus, but I'll accept that it is possible. Wouldn't the better solution be to allow global hotkeys, but to give priority to the menu/applet if any of them happen to set Fn+PrntScrn etc as a shortcut?

Aaron, better to argue upstream, they know why they did that better

Apparently:

Comment #1 from Matthias Clasen (gtk+ developer, points: 26)
2006-08-05 18:42 UTC [reply]

This can't work, due the way menus are implemented in X11.

So it looks more like an X11 bug than a policy choice. Should this bug be filed against X11? There isn't a lot of detail to work with...

is this gonna stay "wontfix"?

i consider this a true bug (maybe wishlist importance) because even though there maybe technical reasons that this cannot(doesnot) work there are no semantic reasons why this is not something useful to have. and the incoming duplicates confirm that users expect this to work.

my favorite example is that you cannot make screenshots of menus (well, "sleep 5; gnome-screenshot" does the trick)

could this be reopend as wishlist at least?

The xinput program (xinput test <device id>) exhibits the proper XGrabKeyboard() bypass behavior.

I agree with Michael in that this is fairly critical. Please count my vote
on reopening the issue.
--
Nicholas

On Sat, Feb 14, 2009 at 2:59 PM, Charles Huber <email address hidden> wrote:

> The xinput program (xinput test <device id>) exhibits the proper
> XGrabKeyboard() bypass behavior.
>
> --
> Can't use any global keyboard shortcuts or hotkeys when applet/menu is open
> https://bugs.launchpad.net/bugs/10905
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>
> Status in gtk: Won't Fix
> Status in "gtk+2.0" source package in Ubuntu: Invalid
>
> Bug description:
> Hi,
>
> Reproduce scenario :
> - left click on an applet
> - try the ^-Alt arrow to switch desktop
>
> When an applet contextual menu is opened, you can't switch desktop with
> keyboard
> shortcuts.
> Normally,we should have a consistent behaviour in regards with the
> workspace-selector
> applet, ie :
> - first ^-Alt-arrow (for the workspace-selector : click), the menu is
> unfolded
> - second ^-Alt-arrow , we go to the next desktop
>
> What do you reckon ?
>
> regards,
> mr
>

--
Nicholas
678.231.0946
AIM: nicholasalipaz
GTalk: <email address hidden>
MSN: <email address hidden>
Y!: nicholas.alipaz
ICQ: 439319956
MySpace IM: <email address hidden>

It would be very nice to use some shortcuts like screenshot and media player commands (play, next track). These shouldn't conflict with anything.

Is this a duplicate of 29894?
or is 29894 a duplicate of this?

the other one would be a duplicate but this one is closed as a gtk bug and the other one is accepted as a gnome-screenshot workaround so you can let them this way

an inconsistent user interface is a design choice?

What is this, windows???

Well spoken Nathaniel.

Also, a nasty side effect of this is that gksudo segfaults when run whilst a menu is open, sometimes also throwing in a scary-looking "Someone is trying to hijack you mouse!"-warning

"Someone is trying to hijack you mouse!" i hate that when happens. but it happens a lot to me!! :)

What a terrible design choice, this badly needs a new implantation!

Massive cross-stack issue to fix (too much for a papercut) but something that will need to be worked around eventually; even if the solution is something that's not X, not Gtk+ and doesn't involve invasive grabs.

I at least expect to be able to CHANGE VOLUME with the keyboard when the SOUND APPLET is open. This isn't a high priortity bug but it definitely shouldn't be a 'won't-fix'.

@Robert Carr; I've assigned this to you as it might be related to the general focus grabbing issue you are looking into at the moment (Launcher reveal when menu is open, clicking outside of the Dash, etc...), please un-assign yourself if this is incorrect.

This bug has been reported on the Ubuntu localized ISO testing tracker.

A list of all reports related to this bug can be found here:
http://localized-iso.qa.ubuntu.com/qatracker/reports/bugs/10905

I can confirm this on 12.04 up to date. Another problem is that, when viewing an indicator drop-down menu (or even a right click menu on anything or a classic app menu from the global menu), you can reveal the launcher with the pointer, but it acts weirdly: it hides more quickly, it doesn't react when an icon is clicked, the names of the apps don't appear, the stacked icons don't spread...

Can't we just make it impossible to reveal the launcher when a menu is open so the behaviour of the launcher doesn't seem inconsistent or buggy?

Strange enough in Xubuntu this problem does not occur with the date-time settings in the upper right corner, while it does occur with any of the other application indicators on Xubuntu. What's different about that solution?

Maybe I'm missing something, just wanted to mention it in case it helps.

For me the main problem with this bug is when leaving the desk I stop usual the music by clicking
the pause button in the sound indicator and often press then CTRL + ALT + L (a matter of
habit) to lock the screen, but it doesn't lock cause of this bug. This is a security
problem. I have documents on my machine that should not be accessible by unauthorized
people but from time to time I have to leaf my desk :)

In Ubuntu 12.10 (using the Unity desktop) you can typically perform a screenshot by pressing the "Print Screen" button on you keyboard. This launches gnome-screenshot, and you are given a dialog allowing you to save that screenshot to a file system location.

However, this does not work if you have activated a context-menu of an indicator/applet by the clock. I'm specifically trying to take a screenshot that showcases the contents of the network-manager's context menu for another bug ( https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1078662 ). However, while that context menu is displayed, the "Print Screen" button doesn't launch gnome-screenshot.

Another example would be if you wanted to take a screenshot of your desktop with the clock's calendar showcased. To reproduce:
1) Click on the clock (to display its calendar)
2) Hit the "Print Screen" button
3) Nothing happens ( gnome-screenshot is not launched as expected).

ProblemType: Bug
DistroRelease: Ubuntu 12.10
Package: gnome-screenshot 3.6.0-0ubuntu1
ProcVersionSignature: Ubuntu 3.5.0-18.29-generic 3.5.7
Uname: Linux 3.5.0-18-generic x86_64
ApportVersion: 2.6.1-0ubuntu6
Architecture: amd64
Date: Wed Nov 14 20:03:29 2012
InstallationDate: Installed on 2012-10-19 (26 days ago)
InstallationMedia: Ubuntu 12.10 "Quantal Quetzal" - Release amd64 (20121017.5)
MarkForUpload: True
ProcEnviron:
 TERM=xterm
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: gnome-screenshot
UpgradeStatus: No upgrade log present (probably fresh install)

When an appindicator is opened, the dashboard isn't showing when the shortcut pressed!

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

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

Fix Released in Nux Unity 7.1.1.

Is this ever going to be closed? I reported a duplicate bug like this 7 years ago, and the original bug report was 9 years ago....

@Acid_1 your question is unclear: the bug appears closed to me. Perhaps if you revealed a little more context to your question we could be of assistance....

I've read the code in unity/services/panel-service.c
about 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),

but it still does not resolve the problem about PrintScreen key to snapshot context menu.

The root reason is at the XGrabKeyboard in popup_grab_on_window() of gtk/gtkmenu.c.

Guys, don't bother yourself any more, as you know linux means freedom, we could get rid of XGrabKeyboard by ourselves:
http://stackoverflow.com/a/20071469/264181