Verified with both Xfce built from git and on Fedora 29. See: https://forum.xfce.org/viewtopic.php?pid=50351#p50351 When changing an existing keyboard shortcut or creating a new one (success is more frequent), the keyboard shortcut stops working or doesn't work at all. Symptoms are as follows: 1. The panel button depresses but the menu doesn't popup 2. In ~/.xsession-errors I get "(xfce4-panel:561): Gtk-WARNING **: 10:38:24.926: no trigger event for menu popup" 3. If I press the shortcut key again, it seems to ignore this shortcut and goes back to the default (possibly from /etc/xdg.....) 4. I need to click the panel icon to un-depress it to keep it from using the default shortcut.
I can confirm this, too. For me, it only does not work for the "xfce4-popup-applicationsmenu" command (standard shortcut F1). The others work fine. If executed from terminal or via xfce4-appfinder all is OK and only the xfce4-panel-4.13.* versions are affected. Regards, Mikkl
*** Bug 15222 has been marked as a duplicate of this bug. ***
Created attachment 8657 workaround I looked into this, but I was not able to figure out what the issue with gtk_menu_popup_at_widget() is. Maybe something to do with input grabbing. Adding a delay of about 100ms works around this problem (unless you keep holding the shortcut).
*** Bug 15808 has been marked as a duplicate of this bug. ***
Confirming that pressing the keyboard shortcut very works. Note, however, that this is specific to "Applications Menu" (`xfce4-popup-applicationsmenu`), not shortcuts in general. For example, `xfce4-appfinder --collapsed` works no matter how long you press the shortcut, it always works. Maybe it has something to do with the fact that the "applications menu" panel item gets selected: it visually looks like a pressed button when the bug appears, and stays visually "pressed".
EDIT: * Confirming that pressing the keyboard shortcut very FAST works.
Following a discussion with the bug's reporter on xfce forum (https://forum.xfce.org/viewtopic.php?pid=53821), it may be that the following observed behaviour is related to the bug: I have an application shortcut which is bound to a command 'xfce4-popup-applicationsmenu'. Before an upgrade to 4.14, it worked as expected - it poped up an application menu on the same place on the screen where the application menu would have appeared had I clicked an 'Application Menu' button on a panel with the left mouse button. After an upgrade though, it usually runs a command 'xfdesktop --menu' instead. To be more precise, immediately after logging in when I use the shortcut it usually pops up an application menu. After the shortcut is used once or twice (each use is separated by an action which closes the application menu - for example by pressing 'Esc'. Also, number of times the shortcut should be used till the problem starts occurring is not deterministic and change all the time - may be once or twice, may be more), the following press does not pop up an application menu, but causes the application menu button to appear pressed (become 'depressed'), and to stay appear pressed from now on (that is, pressing 'Esc' doesn't change the button's appearance). Then all the following attempts to use the shortcut pop up the same menu which appears when a command 'xfdesktop --menu' is ran. This continues to happen until the application menu button is clicked with the left mouse button - this action pops up application menu. After application menu disappears (for example, if 'Esc' is pressed), application menu stops appearing pressed. If shortcut is pressed again on this stage, the whole cycle described above repeats itself. The same problem happens if shortcut key bound to the command is changed, deleting/recreating the shortcut does not help. Some of this problem is clear, because a shell script xfce4-popup-applicationsmenu runs the following command: /usr/bin/xfce4-panel --plugin-event=applicationsmenu:popup:bool:$ATPOINTER || xfdesktop --menu In other words, a wrong menu is popped up because the command '/usr/bin/xfce4-panel --plugin-event=applicationsmenu:popup:bool:$ATPOINTER' fails. The matter is, that if the command is ran manually from cli (with $ATPOINTER replaced by 'false') in a state when application menu is not depresses, then the command always succeeds and an application menu is always popped up (if application menu is already depressed as the result of using a shortcut as described above, then the command from cli fails with a return code '1' and application menu is not popped up). If I try to bind shortcut key immediately to the command '/usr/bin/xfce4-panel --plugin-event=applicationsmenu:popup:bool:false' instead of to 'xfce4-popup-applicationsmenu', then even if I try to use the shortcut in a state when application menu key is not depressed, the problem occurs (application menu becomes depressed and no application menu pops up). In other words, something is going wrong with the command only when it is executed via a shortcut key. As far as I see, a command fails because a function 'panel_dbus_client_plugin_event' fails (function's return value is 1, while remote_succeed is 0).
I confirm the bug is still present in xfce4-panel version 4.14.1 (despite Target Milestone set to 4.14).
There is no proper fix for this bug yet, so the report is still open. Also, the target milestone remains unchanged unless someone updates it.
I’m experiencing this bug too. My shortcut for the applications menu is Super+Escape. After seeing the workaround in attachment 8657 , I was able to create a simpler workaround by adding a wrapper in /usr/local/bin/xfce4-popup-applicationsmenu: #!/bin/sh sleep 0.1 exec /usr/bin/xfce4-popup-applicationsmenu While this works, if I hold the Escape key for more than 0.1s, I can still reproduce the issue: the applications menu does not appear (presumably it’s cancelled so quickly I can’t even see it), and instead I get xfdesktop --menu to show up instead, as described in comment #7.
I can confirm this bug. The workaround mentioned above works with the same limitation Raffaello described.
-- GitLab Migration Automatic Message -- This bug has been migrated to xfce.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.xfce.org/xfce/xfce4-panel/-/issues/201. Please create an account or use an existing account on one of our supported OAuth providers. If you want to fork to submit patches and merge requests please continue reading here: https://docs.xfce.org/contribute/dev/git/start#gitlab_forks_and_merge_requests Also feel free to reach out to us on the mailing list https://mail.xfce.org/mailman/listinfo/xfce4-dev