205648 - Context menu key binding should use context menu key in addition to Shift+F10

Status: RESOLVED FIXED

(Core :: XUL, defect)

Description

[Ed Catmur]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4b) Gecko/20030503 Mozilla Firebird/0.6
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4b) Gecko/20030503 Mozilla Firebird/0.6

Currently to bring up the context menu one must press Shift+F10.
Most PC keyboards have a 'context menu' key (originally introduced by Microsoft
I think).
The context menu key has a standardised X keycode (117) and a GTK code
(GDK_Menu) and as long as the user's X server is configured properly GTK will
send the GDK_Menu keycode to Mozilla.
Accordingly, we should handle this keycode *in addition to* Shift+F10.
(Shift+F10 should still be handled as not all keyboards/X servers can send this
keycode)
This makes using the context menu easier as it requires one keypress instead of two.
This will also make behaviour on this issue consistent with Windows (where
context menu events are handled by the OS) which is appropriate as most Linux
machines are x86 and have the appropriate keyboard.
This can be implemented with the minimum of extra code.

Reproducible: Always

Steps to Reproduce:

Comment 1

[Ed Catmur]

I reference Bug 36665 and point out that in Bug 81727#6 Marko Macek requests the
XK_Menu key be handled. (Bug 81727 was resolved but this is not a dupe as it
requests extra functionality)

I have a patch which compiles successfully and works (I am using it now).

The files to patch are:

dom/public/idl/events/nsIDOMKeyEvent.idl to add a DOM_VK_CONTEXT_MENU keycode
(Question: what key code should be used? Are these essentially arbitrary or is
there a logic for the non-Unicode keys e.g. Meta? Currently using 0xF0)

widget/public/nsGUIEvent.h to add a NS_VK_CONTEXT_MENU keycode

widget/src/gtk/nsGtkEventHandler.cpp to bind NS_VK_CONTEXT_MENU to GDK_Menu

widget/src/gtk/nsWidget.cpp to handle ContextMenu as well as Shift+F10

As I said, this is a very small change which improves functionality and
accessibility.

Comment 2

[Ed Catmur]

Attachment: Working patch

Comment 3

[Crispin Flowerday (not receiving bug mail)]

Attachment: Updated patch, including gtk2 support

This patch adds the support into the gtk2 widget for the Context Menu key

Comment 4

[Brian Ryner (not reading)]

Comment on attachment 140853 [details] [diff] [review]
Updated patch, including gtk2 support

>+  // context menu key, keysym 0xff67, typically keycode 117 on 105-key (Microsoft) 
>+  // x86 keyboards, located between right 'Windows' key and right Ctrl key
>+  // Incidentally META should be located here to match nsGUIEvent.h

The list doesn't match the order in nsGUIEvent.h in several ways... no need to
comment on this one in particular.

(for both gtk1 and gtk2)

sr=bryner with that change.

Comment 5

[Crispin Flowerday (not receiving bug mail)]

Attachment: Patch v3

Updated patch to reflect bryner's comments.

Comment 6

[Crispin Flowerday (not receiving bug mail)]

Comment on attachment 141405 [details] [diff] [review]
Patch v3

Requesting r=blizzard, and carrying forward sr=bryner

Comment 7

[Christopher Blizzard (:blizzard)]

jst, do the constants listed in nsIDOMKeyEvent come from the standard - i.e. can
we just add to them or not?  Need to know that before I review this.

Comment 8

[Johnny Stenback (:jst)]

No, those constants (that whole interface, really) are things we've made up. The
closest thing to a standard for key events is the upcoming DOM Level 3 Events
(currently a note only) interfaces which we don't have yet. So feel free to add
to those constants.

Comment 9

[Christopher Aillon (sabbatical, not receiving bugmail)]

Actually, (a little history lesson for you all) most of those constants were
once in a DOM Level 2 WD, but you have to go all the way back 5 years to
http://www.w3.org/TR/1999/WD-DOM-Level-2-19990923/events.html#Events-KeyEvent
and earlier to find them.

Comment 10

[Johnny Stenback (:jst)]

Yeah, key events in DOM Level 2 was a lot of fun.

Comment 11

[Crispin Flowerday (not receiving bug mail)]

As pointed out by Neil, the keycodes in nsIDOMKeyEvent bear a stricking
resemblance to the ones in the winuser.h. So before checking this in, we need to
check what keycode windows uses for the menu key. It looks like it should be
0x5D, but this probably needs double checking.

Anyone with a windows box care to check ?

Comment 12

[Crispin Flowerday (not receiving bug mail)]

Attachment: Patch v4, using 0x5D as the keycode

This patch updates the keycode, so that it is the same as the windows event.

Comment 13

[[e-mail]]

Checked in with 0x5D as the keycode.