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.

Changing to All platforms but setting pp, since this involves different fixes on each platform.

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.

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.

On Linux/Unix, Shift+F10 and XK_Menu (on PC mapped to "windows keyboard" menu key) should show the context menu.

Mass-moving all M20-M30 XPToolkit bugs to Future

*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.

*** Bug 54942 has been marked as a duplicate of this bug. ***

*** Bug 54944 has been marked as a duplicate of this bug. ***

*** Bug 54946 has been marked as a duplicate of this bug. ***

'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.

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.

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.

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??

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.

*** Bug 63748 has been marked as a duplicate of this bug. ***

*** Bug 14370 has been marked as a duplicate of this bug. ***

MIchael, doesn't sound like a bad idea, but re-working the current nsXULPopupListener along that lines would just mean a bit o' testing.

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.

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.

ctrl-space makes no sense, however, supporting shift-f10 xp might make sense.

Jesse, Control-Space usually means "clear selection of all formatting" in Windows programs. Aaron

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 :)

*** Bug 71671 has been marked as a duplicate of this bug. ***

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?

As long as VK_APPS is also supported on Windows.

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.

clearing milestone to nominate for beta1/moz0.9.

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.

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.

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?

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?

step in the right direction, r=saari Hyatt, make sure this doesn't "break" context menu firing on mousedown vs. up semantics.

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.

Reassigning to pinkerton, who is going to kick some ass.

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!

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.

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

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.

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?

\/\/hatever

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).

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)

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.

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.

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.

cool. sr=waterson

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?

Bug 72084 may be related to this bug as well. Could someone look into that one too?

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.

Need ETA MM/DD in status whiteboard. Please add ASAP.

Does this really depend on 71923? cuz that has been futured...

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.

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?

i'm curious as to why this is suddenly so important. neither this bug nor it's dependent bug have the embed keyword.

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.

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.

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.

meta bugs don't have target

dependent bugs fixed. marking fixed.

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?

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.

That's bug 81727. Re-closing this one.

Yay. I love it when All/All bugs I file only get fixed on one platform ... Verified fixed based on sairuh's comments.

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.

CC'ing bryner