Keyboard shortcut "Control-Escape" no longer functions

Bug #156814 reported by Nick Holloway
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Xfce4 Desktop
Fix Released
Medium
Xfce4 Panel Menu Plugin
In Progress
Unknown
xfce4-panel-menu-plugin (Ubuntu)
Fix Released
Low
Unassigned

Bug Description

Binary package hint: xfce4-mcs-plugins

I am using the default keyboard shortcuts "/usr/share/xfce-mcs-plugins/shortcuts/default.xml", which includes the setting:

    <shortcut command="xfce4-popup-menu" keys="Control+Escape"/>

I can also see this setting when I open "Keyboard Settings" from the "Settings Menu".

After upgrading from Feisty Fawn to Gutsy Gibbon, hitting "Control+Escape" no longer displays the XFCE menu.

If I run the command "xfce4-popup-menu" directly, the XFCE menu is working, so the fault appears to be the recognition of the keyboard shortcut.

Revision history for this message
In , Romildo (romildo) wrote :

After setting a keyboard shortcut to the command "xfdesktop -menu", the shortcut
does not work. Have tried with Control+Escape and Control+Alt+M

Revision history for this message
In , Andrewski-2 (andrewski-2) wrote :

I can reproduce this with 'xfdesktop -windowlist' also. However, for me, the shortcut works
occasionally.

Revision history for this message
In , Brian Tarricone (kelnos) wrote :

yep, i'm seeing this too. i set the shortcut, and hit it, and the menu pops up.
 click elsewhere to close the menu, hit the shortcut again, and so on. it works
for the first 5 or so times, and then stops working. my other shortcuts (one of
them to bring up a terminal) work fine. running 'xfdesktop -menu' repeatedly
from a terminal works fine.

Revision history for this message
In , William Poetra Yoga Hadisoeseno (williampoetra) wrote :

Well, the launcher didn't work for me, and running it from a console gives a
segfault. This didn't happen in RC2.

Revision history for this message
In , Jasper Huijsmans (jasper) wrote :

(In reply to comment #3)
> Well, the launcher didn't work for me, and running it from a console gives a
> segfault. This didn't happen in RC2.

This is a completely separate issue, please report a new bug. Try to get a
backtrace from the crash in gdb.

Revision history for this message
In , Olivier Fourdan (fourdan) wrote :

Some debugging clearly shows the problem is with xfdesktop and not with xfwm4
because the shortcut is spawned by xfwm4 correctly, xfdesktop send the client
message and the message is received by the running process.

Revision history for this message
In , Brian Tarricone (kelnos) wrote :

As Olivier found, this was caused by the gtk_menu_popup() code not being able to
get a keyboard grab before trying to pop up the menu, causing it to give up.
Solution was to steal a bit of xfwm4's code to wait for a grab (with timeout)
before trying to pop up the window. Fixed in trunk and xfce_4_2. Finally!

Revision history for this message
In , Pasi-ov (pasi-ov) wrote :

Created attachment 322
Proposed solution for the windowlist menu

Sorry to wake up a closed bug...

The same problem applies to the windowlist menu, and the fix is only for the
desktop menu (as of svn revision 18313). Attaching a patch to address the
problem for the windowlist as well.

Revision history for this message
In , Brian Tarricone (kelnos) wrote :

Applied, and stuff.

Revision history for this message
In , Pasi-ov (pasi-ov) wrote :

This bug was reintroduced with the new xfce4-menu. I'm unable to reopen it.

Revision history for this message
In , Xfce (xfce) wrote :

(In reply to comment #9)
> This bug was reintroduced with the new xfce4-menu. I'm unable to reopen it.
>

Revision history for this message
In , Brian Tarricone (kelnos) wrote :

Sorry guys, works fine for me here using 4.4 and SVN trunk. Try killing xfdesktop, then run it from a terminal, and try 'xfdesktop -menu' from another terminal. See what output you get, and post it here.

Revision history for this message
In , Pasi-ov (pasi-ov) wrote :

With SVN built after your post I get this:

[pasi@arch ~]$ xfdesktop & disown
[1] 6289
[pasi@arch ~]$
** (xfdesktop:6289): CRITICAL **: Unable to get keyboard/mouse grab. Unable to popup desktop menu

** (xfdesktop:6289): CRITICAL **: Unable to get keyboard/mouse grab. Unable to popup desktop menu

Every time Ctrl+Esc is hit, and after 20 or so tries the menu finally pops up. `xfdesktop -menu` from command line works fine.

Revision history for this message
In , Pasi-ov (pasi-ov) wrote :

To be accurate, it's one error line per key press.

Revision history for this message
In , Pasi-ov (pasi-ov) wrote :

The problem seems to be related to the speed at which the button combination is pressed. i.e. While Ctrl is kept down, hit and release Esc very quickly -> the menu pops up. If Esc is kept down for a short moment, error is printed.

Revision history for this message
In , Brian Tarricone (kelnos) wrote :

I think there's a separate bug open somewhere about this. This is actually a gtk 2.12 problem, but we can work around it, I think. Can you try current svn? I increased the time it tries to grab the mouse/kbd by 3x.

Revision history for this message
In , Pasi-ov (pasi-ov) wrote :

I'm not quite sure if there's change in it. It is possible that it doesn't require as fast tap-and-release as before, but the change is quite small. I'm running gtk2 2.10.14.

Revision history for this message
In , Brian Tarricone (kelnos) wrote :

Pasi, can you look in xfdesktop/trunk/common/xfdesktop-common.c, line 248? You can mess with the (i++ < 300) value - increasing 300 to something higher will make it try longer. If you can figure out a decent value that gives you close to 100% success, let me know what it is. I personally can't reproduce this, so...

Revision history for this message
In , Pasi-ov (pasi-ov) wrote :

Okay, after a quite a few tests I'd say a value of 2000 makes a pretty safe worksforme value.

Do you have any thoughts on what kind of things in X configuration, for example, might affect this? I'm curious to understand why I'm (so heavily (as in 0.03 vs. 0.2 seconds)) affected by the problem and you're not.

Revision history for this message
In , Brian Tarricone (kelnos) wrote :

(In reply to comment #18)
> Okay, after a quite a few tests I'd say a value of 2000 makes a pretty safe
> worksforme value.
>
> Do you have any thoughts on what kind of things in X configuration, for
> example, might affect this? I'm curious to understand why I'm (so heavily (as
> in 0.03 vs. 0.2 seconds)) affected by the problem and you're not.

Nope, no idea. Do you have a blazing-fast computer with lots of RAM? It occurs to me that 0.03 seconds isn't much time to release a key. My assumption is that the time to load xfdesktop and get to the point where it's doing the grab test dominates, and the 0.03 seconds is just enough for most people. But if you have a really fast computer, the xfdesktop load is really quick? I dunno - just pulling stuff out of my ass here, really.

(Actually, the original value was 100; I upped it to 300 before I asked you to test; so 0.01 seconds was the original timeout.)

Olivier, any ideas? I can change the value to 2000; I don't think 0.2 seconds in a busy-loop is too terrible, but it would be nice to know *why* this is necessary for some people but not others.

Revision history for this message
Jérôme Guelfucci (jerome-guelfucci-deactivatedaccount) wrote :

Thank you for your bug report. I can't reproduce this in gutsy.

Changed in xfce-mcs-plugins:
importance: Undecided → Low
Revision history for this message
Lionel Le Folgoc (mrpouit) wrote :

I was able to reproduce this issue, and there was the following error in my ~/.xsession-errors file:
** (xfce4-menu-plugin:4280): CRITICAL **: Unable to get keyboard/mouse grab.

** (xfce4-menu-plugin:4280): CRITICAL **: Unable to get keyboard/mouse grab.

** (xfce4-menu-plugin:4280): CRITICAL **: Unable to get keyboard/mouse grab.

Changed in xfce-mcs-plugins:
status: New → Confirmed
Revision history for this message
Jérôme Guelfucci (jerome-guelfucci-deactivatedaccount) wrote :

Thanks Lionel, I will report this upstream.

Changed in xfce-mcs-plugins:
status: Confirmed → Triaged
Revision history for this message
Jérôme Guelfucci (jerome-guelfucci-deactivatedaccount) wrote :

Upstream bug for this : http://bugzilla.xfce.org/show_bug.cgi?id=441 and http://bugzilla.xfce.org/show_bug.cgi?id=3234

Launchpad is not set correctly for xfce4-panel-menu-plugin so I can't add them.

Revision history for this message
In , Jsfisher92 (jsfisher92) wrote :

Can anyone explain to a newbie how to change the timing so this works? I follow the basic idea described here, but have no idea what file I'm supposed to edit or how, for xfdesktop. Thanks.

Revision history for this message
Jérôme Guelfucci (jerome-guelfucci-deactivatedaccount) wrote :

Thanks Lionel :)

Changed in xfce4-panel-menu-plugin:
status: Unknown → In Progress
Changed in xfdesktop:
status: Unknown → In Progress
Revision history for this message
In , Brian Tarricone (kelnos) wrote :

Ok, I'm going to set this to 2500 in both 4.4 branch and trunk. After the release this weekend we can see if anyone who only follows stable still has this problem. I think we can live with xfdesktop potentially freezing for 1/4 of a second. We'll close this later if this solution seems workable for everyone.

Revision history for this message
In , Brian Tarricone (kelnos) wrote :

(In reply to comment #20)
> Can anyone explain to a newbie how to change the timing so this works? I follow
> the basic idea described here, but have no idea what file I'm supposed to edit
> or how, for xfdesktop. Thanks.
>

See comment #17.

Revision history for this message
Lionel Le Folgoc (mrpouit) wrote :

I can't reproduce this issue anymore with xfce 4.4.2 on hardy, thus I'm closing the bug. But please reopen it if you experience this issue again.
Thanks.

Changed in xfce4-panel-menu-plugin:
status: Triaged → Fix Released
Revision history for this message
In , Brian Tarricone (kelnos) wrote :

*** Bug 3234 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Eric Koegel (eric-koegel) wrote :
Changed in xfdesktop:
importance: Unknown → Medium
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.