Closed
Bug 36665
Opened 25 years ago
Closed 24 years ago
Keyboard access to context menu
Categories
(Core :: XUL, defect, P1)
Core
XUL
Tracking
()
VERIFIED
FIXED
People
(Reporter: mpt, Assigned: mikepinkerton)
References
Details
(Keywords: access, helpwanted, platform-parity, Whiteboard: waiting on 74410, done at that point. need for embedding 0.9)
Attachments
(7 files)
(deleted),
application/zip
|
Details | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
text/plain
|
Details | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review |
Build: 2000041915, Win98 To reproduce: * Click in the content area of a browser window. * On Windows, press Shift+F10, or Ctrl+Shift+F10, or the context menu key if your keyboard has one. On MacOS, press Ctrl+Space. What should happen: * The context menu for the content area should open in the top left corner of the content area. What actually happens: * Nothing. Shift+F10 is the standard keyboard combination for accessing context menus in Windows (adding Ctrl has no extra effect, but should still work). MacOS doesn't normally have keyboard access to context menus, but since Mozilla is smarter than your average bear with regard to keyboard access on Mac, Ctrl+Space (not Cmd+Space, but Ctrl+Space) seems like the logical shortcut to use -- since Space is the usual equivalent to clicking on Windows and in Mozilla, and since Ctrl is the usual modifier for changing from left-mousebutton-mode to right-mouse-button-mode in MacOS. I guess Unix should have a keyboard shortcut for this too, but I don't know what it should be. Maybe Shift+F10, the same as Windows? Ideally, I should get the context menu for the item with keyboard focus. So I should be able to tab to a link and press Shift+F10 to get the context menu for the link. Or select some text, and press Shift+F10 to get the context menu for selected text. And so on. Copying the people involved with bug 14368, which is for using F10 to activate the main menu bar.
Reporter | ||
Comment 1•25 years ago
|
||
Changing to All platforms but setting pp, since this involves different fixes on each platform.
Comment 2•25 years ago
|
||
Also, a distinct bug but one that I'm sure will get fixed while fixing this one, currently in the 04-19 nightly build on WinNT, Shift+F10 defeats right-clicking to bring up a context menu until the next left-click. Not exactly something likely to happen by accident, but an annoyance for anyone aware of Shift+F10 or the context-menu key and unaware of *this* bug. mpt@mailandnews.com, is the same happening on MacOS after typing Ctrl+Space? As a usability issue for those who prefer to or must avoid using the mouse, these keyboard methods of bringing up a context menu should respect focus. In particular, when focus is on a link, or when focus is on an editbox, the appropriate context menu should come up, just as if a right-click had occured in the same focus area. (Context menus for Editboxes are scheduled for nsbeta2, see bug 6270). NN 4.72 fails to do this, but IE5 gets it right.
Keywords: 4xp
Comment 3•25 years ago
|
||
Hmm, it might help if I read the entire report carefully -- > mpt@mailandnews.com, is the same happening on MacOS after typing Ctrl+Space? D'oh. Nevermind... On Linux, some window managers want to handle the function keys themselves, so Shift-F10 may not be a universal solution -- but the context menu key could be enabled for those whose keyboard have one.
Updated•25 years ago
|
Status: NEW → ASSIGNED
Target Milestone: --- → M20
Comment 4•25 years ago
|
||
On Linux/Unix, Shift+F10 and XK_Menu (on PC mapped to "windows keyboard" menu key) should show the context menu.
Comment 5•25 years ago
|
||
Mass-moving all M20-M30 XPToolkit bugs to Future
Target Milestone: M20 → Future
Comment 6•25 years ago
|
||
*spam*: transferring current XP Menu bugs over to jrgm, the new component owner. feel free to add me to the cc list (unless am the Reporter) of any of these, if you have any questions/etc.
QA Contact: sairuh → jrgm
Comment 10•24 years ago
|
||
'On Linux/Unix, Shift+F10 and XK_Menu (on PC mapped to "windows keyboard" menu key) should show the context menu.' - Marko Not quite. On Windows, it's the applications key, VK_APPS, not the Windows keys, VK_LWIN and VK_RWIN.
Comment 11•24 years ago
|
||
Getting rdf/content/src/nsXULPopupListener.cpp to recognize the appropriate keypresses shouldn't be too tough. I'm wondering how difficult it will be to determine what the active element, from tabbing through elements, is in the document. Right now mouse clicks have X and Y co-ordinates, which can be used to get the target for the context menu. At a glance, it looks like there will have to be another function that takes a target and displays a context menu. This function would have the majority of code that's currently in PreLaunchPopup(), and be called by both PreLaunchPopup() and the key presses. PreLaunchPopup() would just get to the point of determining the target that was clicked on. What I haven't dug into yet is that on these keypresses, we'll need to find out what the active target is in the active document. How to do that, I'm not quite sure yet.
Updated•24 years ago
|
Whiteboard: 3 days
Comment 12•24 years ago
|
||
I think the best way to do this (for Windows at least) is to implement DOM level support for a contextmenu listener. This will allow Shift-F10 to work on Windows, as well as the ContextMenu key on a Windows keyboard. There is another defect I opened though - http://bugzilla.mozilla.org/show_bug.cgi?id=50297 that prevents the WM_CONTEXTMENU on windows from working completely. Is there a platform contextmenu message on *IX at all? I do have a ContextMenuListener implemented, just looking for a bug to check it in on.
Reporter | ||
Comment 13•24 years ago
|
||
Michael, if this was done in the DOM, does that mean it would work when focus was in Web pages, but not work anywhere else??
Comment 14•24 years ago
|
||
It should work everywhere. The event that is added to the DOM is valid for all XUL elements. So essentially we're adding another event like buttonup and buttondown called contextmenu. In XULPopupListener, instead of listening for buttonup on Windows, we listen for contextmenu.
Comment 17•24 years ago
|
||
MIchael, doesn't sound like a bad idea, but re-working the current nsXULPopupListener along that lines would just mean a bit o' testing.
Comment 18•24 years ago
|
||
Well the interfaces could certainly be put in place without impacting any existing code. We could add the potentional for contextmenu events, but as long as no front end was calling them, there would be no problem.
Comment 19•24 years ago
|
||
Is there any real reason not to include Ctrl+Space on all platforms? That's considerably easier to hit than the tiny key on new Windows keyboards, and at least on Windows, the shortcut doesn't seem to be used for anything.
Comment 20•24 years ago
|
||
ctrl-space makes no sense, however, supporting shift-f10 xp might make sense.
Comment 21•24 years ago
|
||
Jesse, Control-Space usually means "clear selection of all formatting" in Windows programs. Aaron
Comment 22•24 years ago
|
||
There are really two issues here to be addressed. 1. Getting WM_CONTEXTMENU to work on platforms that support it (then the keyboard access thing is moot on those platforms) - Windows and OS/2. 2. Deciding what keystroke to use on other platforms. Personally, I think this decision should be made in the frontend and mapped to a contextmenu event. Note that I do have code to enable a DOM contextmenu event. Someday I'll actually attach it to a bug :)
Comment 24•24 years ago
|
||
This is an important bug for the accessibility of the embedding 1.0. The keyboard team has put up a spec at www.mozilla.org/projects/ui/accessibility/mozkeyintro.html. We might once a week to discuss keyboard mappings, please let me know if you'd like to get involved, so we can finally clarify lingering keyboard issues. The keystroke we wish to use for this command is Shift+F10, implemented on all platforms. How can we move forward with this?
Comment 26•24 years ago
|
||
Bug 71923 has been added for support of the VK_APPS key. That is a separate problem from getting some/any keyboard access to context menus ASAP. We need Shift+F10 access to context menus now.
Comment 27•24 years ago
|
||
clearing milestone to nominate for beta1/moz0.9.
Target Milestone: Future → ---
Comment 28•24 years ago
|
||
I agree that an oncontextmenu event is needed. This would simply embedding as well. If mkaply has a patch to add this event, please attach it to this bug, so we can get it checked in and rework the popup listener and the embedding listeners to use it.
Updated•24 years ago
|
Target Milestone: --- → mozilla1.0
Comment 29•24 years ago
|
||
Updated•24 years ago
|
Severity: minor → major
Priority: P3 → P1
Comment 30•24 years ago
|
||
Sorry to change the target milestone on you Dave, but this one's crucial for our requirement for keyboard access to all content - in embedding 1.0.
Target Milestone: mozilla1.0 → mozilla0.9
Comment 31•24 years ago
|
||
Comment 32•24 years ago
|
||
Comment 33•24 years ago
|
||
This patch is a good start. Here is what's missing. (1) BOTH HTML and XUL need to have their maps of event handlers patched to add "oncontextmenu", so that you can say something like: <button oncontextmenu="la"/> (2) XBL needs an nsXBLContextMenuHandler to go along with its other handlers. I'm willing to do that part I suppose. Does your patch stop XP_PCs from bringing up a context menu on a mousedown? Is it the firing of the different message in the widget code that does this?
Comment 34•24 years ago
|
||
sr=hyatt. I can make the remaining changes once this is in. Let's get an r= on the patch. saari or pinkerton, can you do the honors?
Comment 35•24 years ago
|
||
step in the right direction, r=saari Hyatt, make sure this doesn't "break" context menu firing on mousedown vs. up semantics.
Comment 36•24 years ago
|
||
How about for now I'll just leave out the nsWindow change and nsXULPopupListener.cpp change and just get the event structure in. That way we don't affect any existing code.
Comment 37•24 years ago
|
||
Reassigning to pinkerton, who is going to kick some ass.
Assignee: hyatt → pinkerton
Status: ASSIGNED → NEW
Assignee | ||
Comment 38•24 years ago
|
||
mkaply - can you attach a new patch which is just everything you haven't checked in? that'll make it easier for me to apply what remains. thanks!
Comment 39•24 years ago
|
||
Comment 40•24 years ago
|
||
Assignee | ||
Comment 41•24 years ago
|
||
ok, here's a big problem. right click, and then right-click to select something from the context menu. Guess what, you get another context menu ;) one way to fix this would be to prevent sending the context-click event into gecko when a popup was being displayed, but I'm not sure if i like that idea.
Assignee | ||
Comment 42•24 years ago
|
||
i have a fix, but i have to talk to hyatt about it. it involves only listening for NS_CONTEXTMENU in menus, and preventing the event from bubbling so that the popup listener doesn't see it again. Index: nsMenuFrame.cpp =================================================================== RCS file: /cvsroot/mozilla/layout/xul/base/src/nsMenuFrame.cpp,v retrieving revision 1.171 diff -c -r1.171 nsMenuFrame.cpp *** nsMenuFrame.cpp 2001/03/23 02:56:09 1.171 --- nsMenuFrame.cpp 2001/03/28 23:30:23 *************** *** 348,359 **** OpenMenu(PR_TRUE); } } ! else if ( aEvent->message == NS_MOUSE_RIGHT_BUTTON_UP && mMenuParent && ! IsDisabled()) { // if this menu is a context menu it accepts right-clicks...fire away! PRBool isContextMenu = PR_FALSE; mMenuParent->GetIsContextMenu(isContextMenu); ! if ( isContextMenu ) Execute(); } else if (aEvent->message == NS_MOUSE_LEFT_BUTTON_UP && !IsMenu() && mMenuParent && !IsDisabled()) { // First, flip "checked" state if we're a checkbox menu, or --- 348,362 ---- OpenMenu(PR_TRUE); } } ! // else if ( aEvent->message == NS_MOUSE_RIGHT_BUTTON_UP && mMenuParent && ! IsDisabled()) { ! else if ( aEvent->message == NS_CONTEXTMENU && mMenuParent && !IsDisabled ()) { // if this menu is a context menu it accepts right-clicks...fire away! PRBool isContextMenu = PR_FALSE; mMenuParent->GetIsContextMenu(isContextMenu); ! if ( isContextMenu ) { ! *aEventStatus = nsEventStatus_eConsumeNoDefault; Execute(); + } } else if (aEvent->message == NS_MOUSE_LEFT_BUTTON_UP && !IsMenu() && mMenuParent && !IsDisabled()) { // First, flip "checked" state if we're a checkbox menu, or
Status: NEW → ASSIGNED
Comment 43•24 years ago
|
||
Should we be planning for eventually having menus off of menus, such as the Start Menu on Win2000 does now? I can see this being useful for Bookmarks. Right-click a bookmark and go.
Comment 44•24 years ago
|
||
either way, the context menu should be handling the event, not its parent. for normal menus i think it's ok for a right click to be treated as a normal click. and for special menus it should allow the context menu to spawn another context menu. perhaps context menus should be derived from <iframe>s which naturally prevent bubbling?
Assignee | ||
Comment 46•24 years ago
|
||
mkaply: the question I have for you before I land this is this: "does os/2 show context menus on mouse down or mouse up? ie, is it the same as win32?" I just need to know which way to ifdef nsMenuFrame. (r=saari and sr=hyatt on all this too).
Assignee | ||
Comment 47•24 years ago
|
||
this is all checked in on win32. what remains is thus: - convert mac/unix widget libraries to send NS_CONTEXTMENU event into gecko - convert embedding to use new context menu DOM event (in my tree)
Comment 48•24 years ago
|
||
Looks good so far, but there's a big thing missing here. When I use VK_APPS to bring up a context menu, it works. This is a good. But the context menu applies to whatever's under the pointer, wherever that may be. For example, tab to this link: bug 16766 and move your pointer over this link: bug 45108 . Press the application key (VK_APPS) and select Open Link In New Window. You'd expect a window with 16766 to open, but it's actually 45108. This no less confusing if the pointer is over a blank area of the document, because there's no link-related menu options at all.
Assignee | ||
Comment 49•24 years ago
|
||
notes: - hyatt and I are going to add an xbl event handler for contextmenu to menus that just calls preventDefault. This will fix the problems where we're not correctly dismissing context menus on a context click. To do this, hyatt will have to add this support to xbl - at some point, we should probably go back to ignoring the WM_CONTEXTMENU on win32 and just handle the keys/clicks in the ESM. That way, we have full control over the ordering of events and can do things like not dispatch context clicks when the user is clicking on a menu, etc (which we can do from the ESM but not from widget). - i have the mac code that uses NS_CONTEXTMENU ready to go.
Comment 50•24 years ago
|
||
here comes a patch to complete the context menu work. I also filled in some gaps where mutation events were not doing the right thing.
Comment 51•24 years ago
|
||
Comment 52•24 years ago
|
||
Assignee | ||
Comment 54•24 years ago
|
||
what is left here? my guess is that it's mainly the fact that the context menu event from the widget code uses the mouse position, not the currently focussed element. I'm going to open a new bug and make it a dependency of this, and move this out to 0.9.1. should i still own this?
Target Milestone: mozilla0.9 → mozilla0.9.1
Comment 55•24 years ago
|
||
Bug 72084 may be related to this bug as well. Could someone look into that one too?
Comment 56•24 years ago
|
||
Sorry I didn't catch this before, but shift+f10 must bring up a context menu for the <i>currently focused item</i>, *not* what's under the mouse pointer. It also needs to work for all platforms, not just Windows.
Assignee | ||
Updated•24 years ago
|
Whiteboard: 3 days → waiting on 74410, no eta
Updated•24 years ago
|
Whiteboard: waiting on 74410, no eta → waiting on 74410, no eta. need for embedding 0.9
Comment 59•24 years ago
|
||
I don't think so. I actually don't think that bug 71923 is valid anymore. We have VK_APPS thanks to this bug, and we don't need VK_LWIN and VK_RWIN support. But this definitely depends on bug 74410.
Comment 60•24 years ago
|
||
Pink, I took a look at this last night, and I see we're very platform-specific the way we do this. Will we need special code for each platform to process Shift+F10? If not, where can we put that? I also looked into having the event indicate a frame that it applies to, rather than the current mouse coordinates. When windows fires a WM_CONTEXT_MENU event, the lParam is 0xffffffff if it was done via the keyboard. Normally the lParam has the mouse coordinates. How can we create a proper NS_CONTEXTMENU event for nsEventListenerManager.cpp that has the correct frame, rather than coordinates?
Assignee | ||
Comment 61•24 years ago
|
||
i'm curious as to why this is suddenly so important. neither this bug nor it's dependent bug have the embed keyword.
Comment 62•24 years ago
|
||
Me too. Context menus shouldn't be the only way to execute a command. If users could still access all major functionality from the keyboard without this, then I think we should consider postponing this work.
Comment 63•24 years ago
|
||
I don't believe that Open Link in New Window, Edit Link in Composer, View Image, Save Form Data, Copy Link Location, and Properties, to name a few, can be accessed from anywhere other than the context menu.
Reporter | ||
Comment 64•24 years ago
|
||
See bug 34357 (which refers to this bug) for discussion of why there are some things in the context menus which can't also be accessed from elsewhere.
Assignee | ||
Updated•24 years ago
|
Whiteboard: waiting on 74410, no eta. need for embedding 0.9 → waiting on 74410, done at that point. need for embedding 0.9
Assignee | ||
Comment 66•24 years ago
|
||
dependent bugs fixed. marking fixed.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Comment 67•24 years ago
|
||
pink: using 2001.05.18.13 comm verif bits, i cannot bring up the context menu using shift+F10 on linux or mac. the cursor just disappears for a bit. is there another bug [other than bug 74410] which still needs to get fixed for this to work?
Reporter | ||
Comment 68•24 years ago
|
||
Reopening. Control+Space still doesn't open the context menu in build 2001052115 on Mac OS, and going by sairuh's comments Shift+F10 doesn't open the context menu on Linux either.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 69•24 years ago
|
||
That's bug 81727. Re-closing this one.
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 70•24 years ago
|
||
Yay. I love it when All/All bugs I file only get fixed on one platform ... Verified fixed based on sairuh's comments.
Status: RESOLVED → VERIFIED
Comment 71•22 years ago
|
||
This bug has re-appeared. Or actually it has re-appeared in composer and mail windows. See bugs 54944 and 54946, which has been closed long ago and marked as duplicates of this one. Either this or those other two mentioned need to be re-opened. Also see bug 202079, which then is a duplicate of whichever gets re-opened.
Component: XP Toolkit/Widgets: Menus → XUL
QA Contact: jrgmorrison → xptoolkit.widgets
You need to log in
before you can comment on or make changes to this bug.
Description
•