Hotkeys with <Super> modifier overriding each other

[Shuhao]

Steps to reproduce:

1. Add a keyboard shortcut to F12. Put it to `notify-send "F12"`
2. Press F12 to verify that it works.
3. Add a second keyboard shortcut to <Super>F12. Put it to `notify-send "Super F12"`
4. Press Super+F12. Verify that Super F12 shows up.
5. Press F12. Sees Super F12 shows up again when F12 should show up.

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: xfwm4 4.11.1-2ubuntu1
ProcVersionSignature: Ubuntu 3.13.0-23.45-generic 3.13.8
Uname: Linux 3.13.0-23-generic x86_64
ApportVersion: 2.14.1-0ubuntu1
Architecture: amd64
CurrentDesktop: XFCE
Date: Sun Apr 6 13:07:27 2014
InstallationDate: Installed on 2013-07-08 (272 days ago)
InstallationMedia: Xubuntu 13.04 "Raring Ringtail" - Release amd64 (20130423.1)
ProcEnviron:
 LANGUAGE=en_US
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/zsh
SourcePackage: xfwm4
UpgradeStatus: Upgraded to trusty on 2014-04-05 (1 days ago)

[Harald Judt (hjudt)]

http://git.xfce.org/xfce/libxfce4ui/commit/?id=e56596a37ffdb4fe8fda4491466e6f826270accc:

From e56596a37ffdb4fe8fda4491466e6f826270accc Mon Sep 17 00:00:00 2001
From: Jérôme Guelfucci <email address hidden>
Date: Tue, 18 Dec 2012 07:21:03 +0000
Subject: Improve key comparison.

Remove horrible hardcoded hack and use the recommanded way of comparison
described in the GDK documentation instead.

--

I gave the 4.11 a try and am now suffering from this bug:

Steps to reproduce:
1) Assign a command "a" to a key e.g. XF86Sleep.
2) Assign a command "b" to that same key but with <Super> modifier: <Super>XF86Sleep.

The settings dialog handles and shows these assignments correctly, and using xfce4-settings-editor, one can confirm that these assignments are correctly saved.

3a) Hit XF86Sleep.
3b) Hit <Super>XF86Sleep.

Expected results:
In case 3a), command "a" is executed.
In case 3b), command "b" is executed.

Actual results:
In both cases 3a) and 3b), command "a" is executed.

DBG[xfce-shortcuts-provider.c:288] xfce_shortcuts_provider_property_changed(): property = /commands/custom/<Super>XF86Calculator
TRACE[xfce-shortcuts-grabber.c:311] xfce_shortcuts_grabber_grab(): Grabbing <Mod4><Super>XF86Calculator
TRACE[xfce-shortcuts-grabber.c:315] xfce_shortcuts_grabber_grab(): Keyval: 269025053
TRACE[xfce-shortcuts-grabber.c:316] xfce_shortcuts_grabber_grab(): Modifiers: 0x4000040
TRACE[xfce-shortcuts-grabber.c:355] xfce_shortcuts_grabber_grab(): Keycode: 148

TRACE[xfce-shortcuts-grabber.c:519] xfce_shortcuts_grabber_event_filter(): Looking for XF86Calculator
...
TRACE[xfce-shortcuts-grabber.c:449] find_event_key(): Comparing to <Super>XF86Calculator
TRACE[xfce-shortcuts-grabber.c:457] find_event_key(): Positive match for <Super>XF86Calculator
...
TRACE[xfce-shortcuts-grabber.c:457] find_event_key(): Positive match for XF86Calculator

Note how the grabber didn't respect our <Super> key.

The same works fine with the <Shift> key:

DBG[xfce-shortcuts-provider.c:288] xfce_shortcuts_provider_property_changed(): property = /commands/custom/<Shift>XF86Calculator
TRACE[xfce-shortcuts-grabber.c:311] xfce_shortcuts_grabber_grab(): Grabbing <Shift>XF86Calculator
TRACE[xfce-shortcuts-grabber.c:315] xfce_shortcuts_grabber_grab(): Keyval: 269025053
TRACE[xfce-shortcuts-grabber.c:316] xfce_shortcuts_grabber_grab(): Modifiers: 0x1
TRACE[xfce-shortcuts-grabber.c:355] xfce_shortcuts_grabber_grab(): Keycode: 148

TRACE[xfce-shortcuts-grabber.c:519] xfce_shortcuts_grabber_event_filter(): Looking for <Shift>XF86Calculator
...
TRACE[xfce-shortcuts-grabber.c:449] find_event_key(): Comparing to <Shift>XF86Calculator
TRACE[xfce-shortcuts-grabber.c:457] find_event_key(): Positive match for <Shift>XF86Calculator
...

And here is the old grabber version:
TRACE[xfce-shortcuts-grabber.c:526] xfce_shortcuts_grabber_event_filter(): Looking for <Hyper><Super>XF86Calculator

[Harald Judt (hjudt)]

Created attachment 5171
restore-super-key-functionality-hack.patch

Attached is a patch that fixes this problem *for me*. Note that it might not (read: certainly will not) work for all configurations and is only a rude hack.

It looks for the mod4 modifier and whenever it finds one, it deletes it and restores it as the super modifier, which can be matched in find_event_key, which I had to patch too (see the hack). A similar fix might be needed for other GDK modifiers (hyper, super...).

I'm sure it can be done in a better way, but at the moment I can't spend more time on it.

[Harald Judt (hjudt)]

Some sort of drawback with that hack is that the shortcuts are now displayed as if the <shift> modifier had been pressed. Examples: <a> is displayed as A, <Shift><a> as <Shift>A. Verifying in xfce4-settings-editor, it is stored properly as <Shift>a and it works correctly too.

[Launchpad Janitor (janitor)]

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

[Shuhao (shuhao)]

Can we get a resolution to this?

[Shuhao (shuhao)]

Is it possible to fix this? Since it is a regression is it possible for us to revert that commit?

This functionality is of importance as I map <SUPER>F11 to single screen and <SUPER>F12 to multiscreen.

[Steve Dodier-Lazaro (sidi)]

(In reply to Harald Judt from comment #2)
> Some sort of drawback with that hack is that the shortcuts are now displayed
> as if the <shift> modifier had been pressed. Examples: <a> is displayed as
> A, <Shift><a> as <Shift>A. Verifying in xfce4-settings-editor, it is stored
> properly as <Shift>a and it works correctly too.

Isn't that just how the UI displays all shortcuts?

[Steve Dodier-Lazaro (sidi)]

I've done a bit of testing just now and could not reproduce the issue in the way it is described.

Steps to reproduce:
1) Assign command "A" to key "A" e.g., notify-send "no mods"
2) Assign command "S" to key "Super+A" e.g., notify-send "super"
3) Assign command "C" to key "Ctrl+Super+A" e.g., notify-send "ctrl+super"
4) Keep in mind Ctrl+A is already assigned to Select All
5* Press A, notice command S runs instead of command A
6) Press Super+A, command S runs
7) Press Ctrl+A, Select All is performed on focused selectable
8) Press Ctrl+Super+A, command C runs

Analysis:
libfxce4ui treats input coming without modifiers as if it had the "Super" modifier. However, the presence of another modifier will prevent libxfce4ui from ignoring the fact that "Super" isn't set.

Expected behaviour on above steps:
5* A runs A
6) Super+A runs S (current behaviour)
7) Ctrl+A runs Select All (current behaviour)
8) Ctrl+Super+A runs C, provided the two modifiers are pressed before A (current behaviour)

NB this bug does not appear related to priority issues between keys and mods as discussed in other reports.

[Harald Judt (hjudt)]

(In reply to Steve Dodier-Lazaro from comment #4)
> (In reply to Harald Judt from comment #2)
> > Some sort of drawback with that hack is that the shortcuts are now displayed
> > as if the <shift> modifier had been pressed. Examples: <a> is displayed as
> > A, <Shift><a> as <Shift>A. Verifying in xfce4-settings-editor, it is stored
> > properly as <Shift>a and it works correctly too.
>
> Isn't that just how the UI displays all shortcuts?

I don't think so. Behold the difference in the key assignment dialog (the small dialog where you enter the shortcuts) and the results in the keyboard shortcut list. IMO, they should be the same.

[Harald Judt (hjudt)]

Sorry, my last comment might not have been very helpful. Another attempt:

> Isn't that just how the UI displays all shortcuts?
It is, but the way it does without what I call the hack seems to be the right one, that is:

<a> => a
<shift>+<a> => A
<super>+<a> => Super + a
<super>+<shift>+<a> => Super + A

"The hack" - you might call it "workaround" - works, and I've been using it happily for over a year now. However, I do not believe it is the proper solution. The proper solution would be to find out what causes the mod4/super modifier to not be recognized correctly. So, as a result of such a proper solution, we should see the above correct GTK presentation of shortcuts with correct functionality.

On the other hand, the hack might be necessary, even with these optical aberrations. Because another complication here might be the difference between the presentation and parsing that presentation. Note that there are other exceptions that had to be made, see bug #8744:

  /* If Shift was used when translating the keyboard state, we remove it
   * from the consumed bit because gtk_accelerator_{name,parse} fail to
   * handle this correctly. This allows us to have shortcuts with Shift
   * as a modifier key (see bug #8744). */
  if ((modifiers & GDK_SHIFT_MASK) && (consumed & GDK_SHIFT_MASK))
    consumed &= ~GDK_SHIFT_MASK;

You will notice that these keyboard shortcut grabber bugs are my favourites ;-)

[Harald Judt (hjudt)]

I can no longer reproduce this. I will check on other machines and close this bug after verification.

[Shuhao (shuhao)]

Which setup? I can still reproduce this

[Harald Judt (hjudt)]

Shuhao, please try the patch in this bug report and report back if it changes anything for you.

[Harald Judt (hjudt)]

Another weird thing:

When I add a non-existing command, e.g. "b" for <super><b> and "bsh" for <super><shift>b, the presentation in the error dialog that opens when trying to exiting this command via the shortcut differs from that in the xfce4-settings dialog (and assignment dialog).

In the error dialog, it is written as above, while in the other two dialogs they are presented with a capital letter B.

This is both with and without my patch, however.

What's more strange: After I have assigned the command bsh to <super><shift><b> and hit this shortcut combination, the error message appears, but also a notification that bouncing keys have been enabled/disabled. Interestingly, this is not reflected in the xfce4-accessibility-settings.

[Shuhao (shuhao)]

By no longer reproduce this you mean with the patch attached?

[Harald Judt (hjudt)]

(In reply to Shuhao from comment #12)
> By no longer reproduce this you mean with the patch attached?

No, without the patch. Sorry, but why don't you simply try the patch and see if it solves your problem?

[Kyrill Detinov (lazy-kent)]

The <Super> modifier seems doesn't work.

There is a quote from opensuse-xfce mailing list:
http://lists.opensuse.org/opensuse-xfce/2014-12/msg00002.html

[Shuhao (shuhao)]

What do we need for info? I'm not sure on how to compile it and actually get it to take effects on Xubuntu... so I'm not sure how I can test the patch

[Hjudt-l (hjudt-l)]

Simple steps for a start, best thing is to pay a visit to #xfce-dev on IRC and ask there in case of troubles:

0) Make sure you have all requirements installed (header packages etc.; autogen will tell you if something is missing, but often not exactly what and it depends on your distribution).
1) Check out the latest git version: git clone git://git.xfce.org/xfce/libxfce4ui
2) Apply the patch with patch -p1 < restore-super-key-functionality-hack.patch.
3) Execute ./autogen.sh --prefix=/usr
   make
   make install

[Hjudt-l (hjudt-l)]

As discovered and confirmed on IRC, this bug is still reproducible with combinations like these:

<Super>-<F12>: xfce4-about
<F12>: xfrun4

[Hjudt-l (hjudt-l)]

I have properly commented and applied the "fix" in http://git.xfce.org/xfce/libxfce4ui/commit/?id=b680e8b9f6b0cf1c706ed430a548590daa1f4565.

Let's hope this does not break anything, and someone finds a proper solution one day.

[Launchpad Janitor (janitor)]

This bug was fixed in the package libxfce4ui - 4.11.2-0ubuntu1

---------------
libxfce4ui (4.11.2-0ubuntu1) vivid; urgency=medium

  * New upstream development release.
    - Drop patches from upstream.
    - Bump required version of intltool.
    - Fix grabbing shortcuts with <Super> modifier. (LP: #1303404)
 -- Unit 193 <email address hidden> Wed, 18 Feb 2015 15:54:00 -0500