Closed Bug 36665 Opened 24 years ago Closed 23 years ago

Keyboard access to context menu

Categories

(Core :: XUL, defect, P1)

Product:
Core
Component:
XUL
Type:
defect

Tracking

()

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

mkaply had sent this to me with big disclaimers - old code
103.79 KB, application/zip
Details
Current diff of DOM mouse stuff
14.57 KB, patch
Details | Diff | Splinter Review
new file - dom/public/coreEvents/nsIDOMContextMenuListener.h
1.57 KB, text/plain
Details
Changes to nsWindow.cpp and nsXULPopuplistener.cpp to actually enable the code
974 bytes, patch
Details | Diff | Splinter Review
Forgot XULPopupListener
1.55 KB, patch
Details | Diff | Splinter Review
patch to content DLL
14.79 KB, patch
Details | Diff | Splinter Review
patch take 2 to content DLL
21.06 KB, 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.
Blocks: 15693
Changing to All platforms but setting pp, since this involves different fixes on 
each platform.
No longer blocks: 15693
Keywords: pp
OS: Windows 95 → All
Hardware: PC → All
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
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.
Status: NEW → ASSIGNED
Target Milestone: --- → M20
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
Target Milestone: M20 → 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.
QA Contact: sairuh → jrgm
Keywords: access
*** 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.
Whiteboard: 3 days
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. ***
Blocks: 15693
MIchael, doesn't sound like a bad idea, but re-working the current 
nsXULPopupListener along that lines would just mean a bit o' testing.
Depends on: 50297
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.
Blocks: 13168
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?
Blocks: 70229
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.
Keywords: helpwanted, mozilla0.9, nsbeta1
Target Milestone: Future → ---
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.
Target Milestone: --- → mozilla1.0
Severity: minor → major
Priority: P3 → P1
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
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.
Assignee: hyatt → pinkerton
Status: ASSIGNED → NEW
Blocks: 18726
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
Status: NEW → ASSIGNED
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
Depends on: 74065
Depends on: 74410

    
    

    
  
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

    
    

    
  
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.

    
  
Depends on: 71923

    
    

    
  
Need ETA MM/DD in status whiteboard. Please add ASAP.
Whiteboard: 3 days → waiting on 74410, no eta

    
  
Whiteboard: waiting on 74410, no eta → waiting on 74410, no eta.  need for embedding 0.9

    
  
Blocks: 75785

    
    

    
  
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.

    
  
No longer depends on: 71923

    
    

    
  
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.
Whiteboard: waiting on 74410, no eta.  need for embedding 0.9 → waiting on 74410, done at that point.  need for embedding 0.9

    
  
Blocks: 65632

    
    

    
  
meta bugs don't have target

Target Milestone: mozilla0.9.1 → ---

    
    

    
  
dependent bugs fixed. marking fixed.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → 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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

    
    

    
  
That's bug 81727.  Re-closing this one.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED

    
    

    
  
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

    
    

    
  
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

    
  
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.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: