Closed
Bug 205648
Opened 22 years ago
Closed 21 years ago
Context menu key binding should use context menu key in addition to Shift+F10
Categories
(Core :: XUL, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: ed, Assigned: crispin)
Details
Attachments
(2 files, 2 obsolete files)
7.27 KB,
patch
|
blizzard
:
review+
crispin
:
superreview+
|
Details | Diff | Splinter Review |
7.25 KB,
patch
|
Details | Diff | Splinter Review |
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:
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.
Assignee | ||
Comment 3•21 years ago
|
||
This patch adds the support into the gtk2 widget for the Context Menu key
Assignee | ||
Updated•21 years ago
|
Attachment #123271 -
Attachment is obsolete: true
Assignee | ||
Updated•21 years ago
|
Assignee: jag → mozilla
Status: UNCONFIRMED → ASSIGNED
Assignee | ||
Updated•21 years ago
|
Attachment #140853 -
Flags: superreview?(bryner)
Attachment #140853 -
Flags: review?(blizzard)
Comment 4•21 years ago
|
||
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.
Attachment #140853 -
Flags: superreview?(bryner) → superreview+
Assignee | ||
Comment 5•21 years ago
|
||
Updated patch to reflect bryner's comments.
Attachment #140853 -
Attachment is obsolete: true
Assignee | ||
Comment 6•21 years ago
|
||
Comment on attachment 141405 [details] [diff] [review] Patch v3 Requesting r=blizzard, and carrying forward sr=bryner
Attachment #141405 -
Flags: superreview+
Attachment #141405 -
Flags: review?(blizzard)
Assignee | ||
Updated•21 years ago
|
Attachment #140853 -
Flags: review?(blizzard)
Comment 7•21 years ago
|
||
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.
Updated•21 years ago
|
Attachment #141405 -
Flags: review?(blizzard)
Comment 8•21 years ago
|
||
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.
Updated•21 years ago
|
Attachment #141405 -
Flags: review+
Comment 9•21 years ago
|
||
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.
Assignee | ||
Comment 11•21 years ago
|
||
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 ?
Assignee | ||
Comment 12•21 years ago
|
||
This patch updates the keycode, so that it is the same as the windows event.
Comment 13•21 years ago
|
||
Checked in with 0x5D as the keycode.
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•