[precise] F10 always opens the menu, cannot be overriden (after xkeyboard-config update)

[Roman Yepishev]

[Impact]
F10 behaves the same as Shift-F10. This causes menus to pop up incorrectly.

[Fix]
Upstream patch preserves Shift so that Shift-F10 and F10 act as separate keys.

[Test Case]
1. Open a gnome-terminal window
2. Run aptitude
3. Press F10

Expected behavior: Aptitude's menu opens
Broken behavior: Menus for both aptitude and gnome-terminal are shown.

In different window environments (e.g. unity) other menus can be triggered than should be.

[Regression Potential]
The patch simply changes a keyboard layout config file, so the severity of any possible regression would be limited to keyboard configuration misbehaviors. This is a well reviewed, tested patch from upstream and not expected to have any regression.

[Original Report]
Upstream bug report: https://bugzilla.gnome.org/show_bug.cgi?id=661973

Visible in Unity - change keybinding for opening first global menu entry to Alt+F10.

Pressing F10 triggers short flash of global menu nevertheless. When you disable the F10 shortcut in gnome-terminal, pressing the key triggers context menu in gnome terminal.

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: libgtk-3-0 3.3.14-0ubuntu4
ProcVersionSignature: Ubuntu 3.2.0-17.26-generic-pae 3.2.6
Uname: Linux 3.2.0-17-generic-pae i686
ApportVersion: 1.92-0ubuntu1
Architecture: i386
Date: Tue Feb 21 16:29:08 2012
InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Alpha i386 (20120119)
SourcePackage: gtk+3.0
UpgradeStatus: No upgrade log present (probably fresh install)

[Christoph Anton Mitterer (calestyo)]

Hi.

This is forwarded from the mentioned Debian bug:

The new version seems to somehow break the F10 key.

When being in GNOME, and havin a gnome-terminal opened, e.g. aptitude running...
pressing F10 should cause aptitude's menu to open.

But now, aptitude's menu opens, as well as the context menu of the terminal itself.

Downgrading fixes the issue.

Cheers,
Chris.

[Sergey V. Udaltsov (svu)]

what does xev utility reports when you press f10?

[Sven Joachim (svenjoac)]

I'm having the same problem with gnome-terminal, here is the xev output:

KeyPress event, serial 33, synthetic NO, window 0x1400001,
    root 0x2b5, subw 0x0, time 11437053, (31,432), root:(964,458),
    state 0x0, keycode 76 (keysym 0xffc7, F10), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyRelease event, serial 33, synthetic NO, window 0x1400001,
    root 0x2b5, subw 0x0, time 11437163, (31,432), root:(964,458),
    state 0x0, keycode 76 (keysym 0xffc7, F10), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

[Sergey V. Udaltsov (svu)]

But according to what I see - it is all correct, F10 produces F10.

What is xev output with the previous version of xkb-data?

> KeyPress event, serial 33, synthetic NO, window 0x1400001,
> root 0x2b5, subw 0x0, time 11437053, (31,432), root:(964,458),
> state 0x0, keycode 76 (keysym 0xffc7, F10), same_screen YES,
> XLookupString gives 0 bytes:
> XmbLookupString gives 0 bytes:
> XFilterEvent returns: False
>
> KeyRelease event, serial 33, synthetic NO, window 0x1400001,
> root 0x2b5, subw 0x0, time 11437163, (31,432), root:(964,458),
> state 0x0, keycode 76 (keysym 0xffc7, F10), same_screen YES,
> XLookupString gives 0 bytes:
> XFilterEvent returns: False

[Sven Joachim (svenjoac)]

With the previous xkb-data version (2.3), it's essentially the same:

KeyPress event, serial 33, synthetic NO, window 0x1600001,
    root 0x2b5, subw 0x0, time 13172000, (-269,319), root:(664,345),
    state 0x0, keycode 76 (keysym 0xffc7, F10), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyRelease event, serial 33, synthetic NO, window 0x1600001,
    root 0x2b5, subw 0x0, time 13172097, (-269,319), root:(664,345),
    state 0x0, keycode 76 (keysym 0xffc7, F10), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

[Sergey V. Udaltsov (svu)]

Well, in that case God knows why gnome-terminal behaves differently.

Ok, one more thing. Could you please do 'xkbcomp :0 -xkb out.xkb' for both new and old versions? Attach the result here

[Sven Joachim (svenjoac)]

Created attachment 55894
xkbcomp output with xkb-data 2.3

[Sven Joachim (svenjoac)]

Created attachment 55895
xkbcomp output with xkb-data 2.5

[Sergey V. Udaltsov (svu)]

The definitions for F10 are different (I expected that, I did that change) - but they should not matter if the XKB events are identical (and they are!).

What I suspect is that some app (gnome-terminal?) somehow checks the key definition. Why? I have no idea. Something was hardcoded - some workaround, perhaps - there was an issue with functional keys in 2.4. But xev output proves there is nothing to fix in xk-c

[Christoph Anton Mitterer (calestyo)]

It's a bit strange simply closing this... and btw: it's not only gnome-terminal that is affected...

[Christoph Anton Mitterer (calestyo)]

(Especially as it's clearly triggered by the new xkb-data version).

[Sergey V. Udaltsov (svu)]

Actually I am ready to reopen if you explain me what exactly would you like me to fix. The x11 (xev) events are absolutely identical - that is the limit of xk-c responsibility, for properly written SW. Is that ok with everybody?

If that's the case, the software is using some other information from XKB config - which is should not, I guess

Returning to the previous version of F10 definition is not an option because it had clearly broken semantics of things like Shift-F10.

So, what would you propose to do?

[Christoph Anton Mitterer (calestyo)]

Well has anyone some idea on whose door we should knock now?

I mean it's probably some GNOME/GTK wide keyboard library or so?

[Sergey V. Udaltsov (svu)]

I would start with gnome-terminal perhaps.

I am really sorry I cannot be of much help. When you open the bug in gnome bugzilla, could you please provide the link here in comments - so that I could participate in the discussion.

Thank you and sorry again.

[Sergey V. Udaltsov (svu)]

I just tried on my debian, F10 opens g-t menu, aptitide seems not getting it at all. Which is reasonable to some extent...

[Sven Joachim (svenjoac)]

To reproduce the problem, you need to configure gnome-terminal to pass F10 to the application. Under "Edit → Keyboard Shortcuts", uncheck "Enable the menu shortcut key (F10 by default)".

[Sergey V. Udaltsov (svu)]

Yes I can reproduce it. That just convinces me that g-t would be a good starting point - I do not know how g-t implements that feature...

[Wettstein509 (wettstein509)]

> The definitions for F10 are different (I expected that, I did that change) ->
> but they should not matter if the XKB events are identical (and they are!).

This is not completely true. The new definition of CTRL+ALT consumes Shift,
the old one does not. With the new definition, in a pedantic interpretation
of section 7.2.1 of the protocol specification of the X Keyboard Extension,
applications must not distinguish Shift-F10 and F10 anymore.

To see wether this is related to problem at hand, one could replace the
definition of CTRL+ALT (file in types/pc) with the following one:

   type "CTRL+ALT" {
 modifiers = Control+Alt+Shift+LevelThree;
        map[None] = Level1;
        map[Shift] = Level2;
        map[LevelThree] = Level3;
        map[Shift+LevelThree] = Level4;
 map[Control+Alt] = Level5;
 preserve[Shift] = Shift;
 preserve[Shift+LevelThree] = Shift;
 preserve[Shift+LevelThree+Alt] = Shift;
 preserve[Shift+LevelThree+Control] = Shift;
 preserve[Shift+LevelThree+Alt+Control] = Shift;
 preserve[Shift+Alt] = Shift;
 preserve[Shift+Alt+Control] = Shift;
 preserve[Shift+Control] = Shift;
        level_name[Level1] = "Base";
        level_name[Level2] = "Shift";
        level_name[Level3] = "Alt Base";
        level_name[Level4] = "Shift Alt";
 level_name[Level5] = "Ctrl+Alt";
    };

I do not have gnome on my machine, so I cannot test myself. Note that
the above definition is still not nice, but should be ok to check wether
consumed Shift is to blame.

> Returning to the previous version of F10 definition is not an option because it
> had clearly broken semantics of things like Shift-F10.

Do you have a pointer where the problems with the old definition are
described?

[Sergey V. Udaltsov (svu)]

> This is not completely true. The new definition of CTRL+ALT consumes Shift,
> the old one does not.
How does it affect the behavior of the F10 when shift is not pressed? As you can see, the events are exactly same.

> Do you have a pointer where the problems with the old definition are
> described?
https://bugs.freedesktop.org/show_bug.cgi?id=11822

[Wettstein509 (wettstein509)]

> How does it affect the behavior of the F10 when shift is not pressed? As you
> can see, the events are exactly same.

Basically, as Shift is consumed, one should not distinguish F10 and
Shift-F10. This means that pressing Shift-F10 should be handled like
pressing F10; or that pressing F10 should be handled like pressing
Shift-F10. So it is imaginable that consuming Shift assigns two functions
to pressing F10: the usual one for F10, plus the one for Shift-F10.

That is the idea. Whether it happens like this, I do not know. One has to
try or read the relevant source code. In any event, the original report
speaks about two actions triggered by F10...

[Christoph Anton Mitterer (calestyo)]

I've reassigned (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=656685#19) the Debian bug to the GNOME guys... hope they can point us to the right place.

[Sven Joachim (svenjoac)]

For the record, this has already been reported in GNOME's bugzilla at https://bugzilla.gnome.org/show_bug.cgi?id=661973.

[Launchpad Janitor (janitor)]

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

[TomaszChmielewski (mangoo-wpkg)]

BTW, the solution suggested in #926611:

    /desktop/gnome/interface/menubar_accel
    /apps/compizconfig-1/profiles/Default/plugins/unityshell/screen0/options/panel_first_menu
    /apps/compiz-1/plugins/unityshell/screen0/options/panel_first_menu

doesn't work for me, as I simply don't have these keys in gconf-editor.

[Roman Yepishev (rye)]

As far as I could read the sources, Shift+F10 handling (which now reacts on F10 too) is hardcoded in GTK and cannot be changed.

[Joost Van Durme (joostvandurme)]

There is a workaround for the context menus in gnome-terminal NOT to open upon pressing F10, it is in post#8 of this thread: https://bbs.archlinux.org/viewtopic.php?id=129872

Create a new file: ~/.config/gtk-3.0/gtk.css, then add this:

@binding-set NoKeyboardNavigation {
 unbind "<shift>F10"
}

* {
 gtk-key-bindings: NoKeyboardNavigation
}

Close all terminal windows and restart terminal.

[mixer3d (mixer3d)]

this solution works for me:
---------------------------------------------------------------------------------------------
There is a workaround for the context menus in gnome-terminal NOT to open upon pressing F10, it is in post#8 of this thread: https://bbs.archlinux.org/viewtopic.php?id=129872

Create a new file: ~/.config/gtk-3.0/gtk.css, then add this:

@binding-set NoKeyboardNavigation {
 unbind "<shift>F10"
}

* {
 gtk-key-bindings: NoKeyboardNavigation
}

Close all terminal windows and restart terminal.
---------------------------------------------------------------------------------

but when i'm press F10 in terminal "~" sign appear, but it's ok now :)

[Chris Bainbridge (chris-bainbridge)]

Arch Linux bug report suggests this is problem is caused by a specific commit to xkeyboard-config https://bugs.archlinux.org/task/26408

[Pavlo Bohmat (bohm)]

Ubuntu 12.04 fluxbox+gnome-terminal: OK, unity+gnome-terminal: Fail...

[Евгений (tatay)]

Please, give us some simple instrument for bind and unbind this "ugly" F10-Menu Key.
We all have habits and their understanding of what means "useful" and what means "inconvenience". Also, in the world, there is the concept of ergonomics.
Managing keys with the "F1" to "F10" in the Midnight Commander - is ergonomical
Better - never try to impose to us such a way to control Menues like your F10 hotkeys. Thx.

[Lukasz Marcinowski (nowymarluk)]

Maybe this will help in this bugreport there is a workaround

https://bugs.launchpad.net/ubuntu/+source/unity/+bug/726639

[Yevgen Muntyan (muntyan-fastmail)]

Could someone take a look at gdk_x11_keymap_translate_keyboard_state () in http://git.gnome.org/browse/gtk+/tree/gdk/x11/gdkkeys-x11.c, and see if they are supposed to be broken? This bug is sitting for six month in the gnome bugzilla now, and it doesn't look like someone knows a definite answer as to what exactly is broken.

[Matthias Clasen (mclasen)]

I'm reopening this.
My own investigation confirms the finding in comment 17.
The xkeyboard-config changes in 2.4.1 make XKB translate Shift-F10 into F10 with level one, while telling my that the Shift modifier got consumed.

[Matthias Clasen (mclasen)]

Also note that xev output being identical is pretty irrelevant here, since xev only reports the core key events, not xkb data. that can be extracted from the combination of key events + xkb maps.

[Matthias Clasen (mclasen)]

    type "CTRL+ALT" {
        modifiers = Control+Alt+Shift+LevelThree;
        map[None] = Level1;
        map[Shift] = Level2;
        map[LevelThree] = Level3;
        map[Shift+LevelThree] = Level4;
        map[Control+Alt] = Level5;
        preserve[Shift] = Shift;
        preserve[Shift+LevelThree] = Shift;
        level_name[Level1] = "Base";
        level_name[Level2] = "Shift";
        level_name[Level3] = "Alt Base";
        level_name[Level4] = "Shift Alt";
        level_name[Level5] = "Ctrl+Alt";
    };

Here is a modified type for CTRL+ALT that works in my testing.
It is similar to the one in comment 17, but avoids blowing up the map with lots of new entries.

With this map, XkbTranslateKeyCode still translates Shift-F10 into F10 at level1, but the Shift modifier is now preserved, so GTK+ uses it when matching accelerators, and thus F10 and Shift-F10 can once again have different bindings.

[Sergey V. Udaltsov (svu)]

Thanks, that idea with preserve looks nice! Pushed.

[luca (llucax)]

Any ETA to see the fix in Ubuntu?

[Sebastien Bacher (seb128)]

quantal is frozen for beta1 so not before next week in quantal, undetermined if and when for other series

[Sebastien Bacher (seb128)]

Hey Bryce, could you have a look at backporting that xkeyboard-config commit for quantal and maybe precise:
http://cgit.freedesktop.org/xkeyboard-config/commit/?id=a4f62448819764f6f27ebcb86115734d0d57ea8d

[Florian Demmer (fdemmer)]

i would very much appreciate a backport to the current LTS as it is a long time till 2014, thank you.

[Launchpad Janitor (janitor)]

This bug was fixed in the package gtk+2.0 - 2.24.13-0ubuntu1

---------------
gtk+2.0 (2.24.13-0ubuntu1) quantal-proposed; urgency=low

  [ Till Kamppeter ]
  * debian/patches/print-dialog-show-options-of-remote-dnssd-printers.patch:
    Make printing on remote DNS-SD/Bonjour-shared printers working
    (LP: #1053891).

  [ Didier Roche ]
  * New upstream release:
    - F10 always opens the menu, cannot be overriden (LP: #937822)
 -- Didier Roche <email address hidden> Mon, 24 Sep 2012 13:56:56 +0200

[Launchpad Janitor (janitor)]

This bug was fixed in the package xkeyboard-config - 2.5-1ubuntu7

---------------
xkeyboard-config (2.5-1ubuntu7) quantal; urgency=low

  * Add patch 114_shift_f10.patch. Don't let Ctrl+Alt consume Shift, else
    it causes Shift-F10 to be treated as F10. This can result in popup
    menus opening when they shouldn't.
    (LP: #937822)
 -- Bryce Harrington <email address hidden> Mon, 24 Sep 2012 15:19:25 -0700

[Scott Kitterman (kitterman)]

Hello Roman, or anyone else affected,

Accepted into precise-proposed. The package will build now and be available in a few hours in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please change the bug tag from verification-needed to verification-done. If it does not, change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Roman Shipovskij (roman-shipovskij)]

Update from precise-proposed does not fix the problem, F10 still opens the context menu in gnome terminal

[Bryce Harrington (bryce)]

@Roman, more details needed.

[Roman Shipovskij (roman-shipovskij)]

After updating from precise-proposed nothing changed, i attached two screenshots to show the problem

[Bryce Harrington (bryce)]

@Roman, I mean details like verifying that you have the right version of xkeyboard-config installed. You may need to reboot, as well.

[Roman Shipovskij (roman-shipovskij)]

Of course I reboot after upgrading

apt-cache policy xkb-data
xkb-data:
  Installed: 2.5-1ubuntu1.4
  Candidate: 2.5-1ubuntu1.4
  Version table:
 *** 2.5-1ubuntu1.4 0
        100 /var/lib/dpkg/status
     2.5-1ubuntu1.3 0
        500 http://archive.ubuntu.com/ubuntu/ precise-updates/main i386 Packages
     2.5-1ubuntu1 0
        500 http://archive.ubuntu.com/ubuntu/ precise/main i386 Packages

[Chris Bainbridge (chris-bainbridge)]

I also confirm that updating to xkb-data-2.5-1ubuntu1.4 does not fix this issue.

There are fixes listed for two packages here, should there be an updated libgtk2.0-0 or some other package in precise-proposed? Or is the fix in xkb-data alone?

[thom (tsk)]

More than a year later this bug is still very prominent in Ubuntu 12.04 LTS.
Half a year ago a fix was committed but hasn't reached the repositories yet ???
(not even in "proposed" or "backports")

If this turns out to be a "won't fix/can't fix for 12.04" situation it might be wise to adopt the following workaround officially
(since it is better than nothing at all):

#-------------------------------------------------------------
mkdir -p ~/.config/gtk-3.0
cat<<EOF > ~/.config/gtk-3.0/gtk.css

@binding-set NoKeyboardNavigation {
     unbind "<shift>F10"
}

* {
     gtk-key-bindings: NoKeyboardNavigation
}

EOF
#--------------------------------------------------------------

[Steve Langasek (vorlon)]

Due to the verification failure, we have removed this package from precise-proposed. When a correct fix has been found, it can be reuploaded to the queue.

[Norbert (nrbrtx)]

I recently installed 12.04 from latest CD-image. The bug is still here. Please fix it before 14.04 release.

[Launchpad Janitor (janitor)]

This bug was fixed in the package xkeyboard-config - 2.5-1ubuntu1.5

---------------
xkeyboard-config (2.5-1ubuntu1.5) precise-proposed; urgency=low

  * Revert last commit due to a SRU verification failure.
  * Add patch 115_add_XF86AudioMicMute.patch. This maps F20 to the new
    XF86AudioMicMute keysym. Cherrypick from upstream. (LP: #408903)
 -- James M Leddy <email address hidden> Fri, 31 May 2013 15:39:35 -0400

[Roman Shipovskij (roman-shipovskij)]

The bug is still exist on 12.04 after upgrading xkeyboard-config to version 2.5-1ubuntu1.5

[Oleg Moiseichuk (berroll)]

I can confirm that upgrading xkb-data package to version 2.5-1ubuntu1.5 in LTS 12.04.4 doesn't resolve the problem. When I disable the mentioned fix in ~/.config/gtk-3.0/gtk.css (F10 is disabled in terminal keyboard combinations), F10 press still opens context menu as if Shift-F10 was pressed.