371777 - Shift+F10 behavior to open context menu is not consistent

Status: NEW

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[Wayne Mery (:wsmwk)]

from Bug 136634 

1. Shift+F10 -> context menu opened
2. Shift+F10 -> context menu closed
3. Shift+F10 

expected results:
open context menu

actual results (windows):
no change
(assuming this will happen for mac + linux, and windows' context key, when 136634 gets fixed)

Pressing Shift+F10 a fourth time opens context menu

Comment 1

[Wayne Mery (:wsmwk)]

It seems trunk behavior has changed. In TB, SM and FF, context menu key now only OPENS the menu, never closes.  Seems like good behavior.  Assuming this is a design change.
=> INVALID.

Comment 2

[Wayne Mery (:wsmwk)]

correction, shift+F10 still the same.  Note: notadupe of bug 136634 which is about context menu.  This bug is about Shift+F10

Comment 3

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Shift+F10 is only used under Windows and it also opens to context menu. So please move it to Windows only or give clear steps what has to be done to get it reproduced on other OS.

Comment 4

[Wayne Mery (:wsmwk)]

I have no means to do that later, so OS=win

Comment 5

[Wayne Mery (:wsmwk)]

I don't know what shift+F10 is supposed to do - but it's behavior is not consistent.  Ref bug 136634 comment 1, 2 and 6

comparison
A.
Shift+F10 -> context menu opened
Shift+F10 -> context menu closed
Shift+F10 (no action)
B.
context-menu-key -> context menu opened
Shift+F10 -> context menu closed
Shift+F10 -> context menu opened
C.
context-menu-key -> context menu opened
context-menu-key -> context menu stays opened

selected windows apps: adobe reader, word
- both shift+F10 and context-menu-key *only* open the menu, don't close the menu

selected windows apps: notepad, windows explorer
- context-menu-key *only* open the menu, don't close the menu
- shift+F10 opens, second shift+F10 closes the menu and move focus to a toolbar or a command menu

Comment 6

[Henrik Skupin [:whimboo][⌚️UTC+2]]

(In reply to comment #5)
> A.
> Shift+F10 -> context menu opened
> Shift+F10 -> context menu closed
> Shift+F10 (no action)

Hit Shift+F10 again and the context menu opens again.

> B.
> context-menu-key -> context menu opened
> Shift+F10 -> context menu closed
> Shift+F10 -> context menu opened
> C.
> context-menu-key -> context menu opened
> context-menu-key -> context menu stays opened

Not able to test both cases due to lacking key under my VmWare. I don't know how to reassign some mappings.

Comment 8

[Brian R. Bondy [:bbondy]]

I think this task should be done, but I wanted to provide more information as to why the bug happens in most programs in Windows. 

In most programs in Windows (For example: notepad)

- First shift+F10: it opens the context
- Second shift+F10: closes the context menu and focuses menu bar
- Third shift+F10: Unfocuses the menu bar (You are back to where you started)
- Fourth shift+F10: Opens the context menu again
 
So when you are about to hit the third shift+F10 you have no context menu on a menu bar so it unfocuses.  In FF you don't see the menu bar by default so it seems inconsistent. 

I think the best way to fix this is after the second Shift+F10 to put the focus back to where it was instead of to the invisible menu bar.

Comment 9

[Wayne Mery (:wsmwk)]

re: comment 8, I see what you mean in notepad. I see this also with notepad++

However, current MS office products on win7 pro shift+F10 ONLY open the context menu, doesn't close it or focus anywhere else.  And in my unedicated opinion this seems to be the correct model, if the intent of F10 is to mimic what happens with right+click mouse which ONLY opens the context menu. Esc may be used to close it.

Wonderful consistency across windows apps - I didn't find any docs from searching the net.
What does accessibility have to say about this?
(Not sure how this squares with bug 136634, and no comments there about accesibility standards)

Comment 10

[Trevor Saunders (:tbsaunde)]

I assume you meant to need info someone else, I don't know anything about this.

Comment 11

[Wayne Mery (:wsmwk)]

Let me clarify .. what I'm interesting in hearing from accessilbility, is what would be ideal behavior from accessibility POV, not what the "OS standard" is or should be.

Comment 12

[Trevor Saunders (:tbsaunde)]

(In reply to Wayne Mery (:wsmwk, use Needinfo for questions) from comment #11)
> Let me clarify .. what I'm interesting in hearing from accessilbility, is
> what would be ideal behavior from accessibility POV, not what the "OS
> standard" is or should be.

no clue

Comment 13

[Andrew Overholt [:overholt]]

(dom-triaged to get this out of queries)

Comment 14

[David Bolter [:davidb] (NeedInfo me for attention)]

I agree with Brian in the end of comment 8, in our case it makes sense to me to not focus the invisible menu bar after the second shift+F10.

Comment 15

[Wayne Mery (:wsmwk)]

clarifying further... the question I have is, shouldn't shift+F10 invoke context menu on every invocation?  
Again, shouldn't it behave precisely like right+click?

Comment 16

[Wayne Mery (:wsmwk)]

Another way of putting it is, I think the behavior in notepad described in comment 8 is exceedingly poor, and shouldn't be used as an example of model behavior at all.

Comment 17

[Marco Zehe (:MarcoZ)]

(In reply to Wayne Mery (:wsmwk, use Needinfo for questions) from comment #15)
> clarifying further... the question I have is, shouldn't shift+F10 invoke
> context menu on every invocation?  
> Again, shouldn't it behave precisely like right+click?

Yes, it should.