1347079 - Cannot block web apps to prevent to open the context menu at trying to open it with Shift+F10 on Windows or Linux

Status: NEW

(Core :: DOM: UI Events & Focus Handling, enhancement, P3)

Description

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Gecko supports that user can block web apps to prevent to open the context menu with Shift key. For instance, Shift+Right-Click and Shift+ContextMenu can open the context menu forcibly.

On Windows and Linux, there is another shortcut key to open context menu, Shift+F10.  However, because Shift state is necessary for this key combination, there is no additional shortcut key to block web apps to prevent to open the context menu when you use this key combination.

So, we should implement Ctrl+Shift+F10 or Alt+Shift+F10 for the purpose. DevTools use Ctrl+Shift+Foo a lot, so, perhaps, we should use Alt+Shift+F10 here.


Any ideas?

Comment 1

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Posted to dev-platform:
https://groups.google.com/forum/#!topic/mozilla.dev.platform/Q-ixkADraqA

Comment 2

[Karl Tomlinson (:karlt)]

I understand that many keyboards do not have any keys configured to send ContextMenu,
but are there some systems or accessibility situations where there is no way for a user to generate mouse events?

If there are, then wouldn't there be bigger problems with pages overriding focus-change keys?

My key question is really "Is there a need to add another override in addition to what is available with Shift+Right-Click?

Comment 3

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to Karl Tomlinson (:karlt) from comment #2)
> I understand that many keyboards do not have any keys configured to send
> ContextMenu,
> but are there some systems or accessibility situations where there is no way
> for a user to generate mouse events?

Could be if mouse is broken or something on desktop machine. Although, must be rare case.

> If there are, then wouldn't there be bigger problems with pages overriding
> focus-change keys?

Good point, I think so. But really different bug. I were struggling with plugin vs. (reserved) shortcut keys, e.g., Ctrl+T, Ctrl+W, etc.  If there are good idea to block web pages to prevent the default of Tab keys, I'd like to implement it if I have much time.  However, Ctrl or Alt + Tab was already reserved by others.  So, I have no idea about the issue.

> My key question is really "Is there a need to add another override in
> addition to what is available with Shift+Right-Click?

I know some users want to navigate only with keyboard in most of the time using Firefox (not majority, probably, though). For such users, a point of view from a11y, the fix of bug 1338369 is a regression on some web apps. Therefore, I think that there should be another shortcut key to open the context menu forcibly.

Comment 4

[u623736]

If I have understood correctly, this "fix" has made it impossible for web apps to block the Context Menu from being displayed by using preventDefault() for example. I think that a similar thing might have been implemented for Alt-F4, which also, unlike other hotkeys seems to be impossible to block in my web app in recent versions of FF. My question for you is why would you do this? If a web app blocks the Context Menu, the loss of functionality to the user on the web app is the fault of the web app developer. Is it not sufficient to leave it at that: bad web app. But your fix seems to have limited what is possible for a web app on FF! My app, which I just use personally, has specific uses for Shift F10 and Alt F4: no one gets hurt by the Context Menu not being displayed because only I use the web app! Shouldn't the web app side be able to decide what is useful for it? Is there a way that I can get around your "fix" for my own purposes? (other than use an old version of FF)

(In reply to Masayuki Nakano [:masayuki] (JST, +0900) from comment #3)
> (In reply to Karl Tomlinson (:karlt) from comment #2)
> > I understand that many keyboards do not have any keys configured to send
> > ContextMenu,
> > but are there some systems or accessibility situations where there is no way
> > for a user to generate mouse events?
> 
> Could be if mouse is broken or something on desktop machine. Although, must
> be rare case.
> 
> > If there are, then wouldn't there be bigger problems with pages overriding
> > focus-change keys?
> 
> Good point, I think so. But really different bug. I were struggling with
> plugin vs. (reserved) shortcut keys, e.g., Ctrl+T, Ctrl+W, etc.  If there
> are good idea to block web pages to prevent the default of Tab keys, I'd
> like to implement it if I have much time.  However, Ctrl or Alt + Tab was
> already reserved by others.  So, I have no idea about the issue.
> 
> > My key question is really "Is there a need to add another override in
> > addition to what is available with Shift+Right-Click?
> 
> I know some users want to navigate only with keyboard in most of the time
> using Firefox (not majority, probably, though). For such users, a point of
> view from a11y, the fix of bug 1338369 is a regression on some web apps.
> Therefore, I think that there should be another shortcut key to open the
> context menu forcibly.

Comment 5

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Some web sites often give inconvenience to any browser users with disabling browser context menu. For example, user may want to use add-on from context menu, navigation menu (back/forward/reload) in context menu, etc, but they are not available if web apps kills the context menu. So, "what is useful" depends on every user. I believe that it's reasonable to make default shortcut key to open context menu cancelable for UX of web apps but there should be bypass to do same thing which cannot be overridden by web apps. This behavior was mentioned by the Living Standards, although it was a part of contextmenu customization which was dropped.

Comment 6

[u623741]

Thank you for your quick response Masayuki. Does that mean that in the current versions of FF, there is no way for me to block the default behavior for SH-F10 and ALT-F4 in my web app? (for example a browser setting)


(In reply to Masayuki Nakano [:masayuki] (JST, +0900) from comment #5)
> Some web sites often give inconvenience to any browser users with disabling
> browser context menu. For example, user may want to use add-on from context
> menu, navigation menu (back/forward/reload) in context menu, etc, but they
> are not available if web apps kills the context menu. So, "what is useful"
> depends on every user. I believe that it's reasonable to make default
> shortcut key to open context menu cancelable for UX of web apps but there
> should be bypass to do same thing which cannot be overridden by web apps.
> This behavior was mentioned by the Living Standards, although it was a part
> of contextmenu customization which was dropped.

Comment 7

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Shift+F10 is cancelable and won't be non-cencelable. This bug's purpose is, to create another shortcut key to open context menu forcibly.

Alt+F4 is really different issue. Most OS reserved shortcut keys are not handled by Firefox nor Gecko. They are just handled by OS (anyway, shouldn't be cancelable. If you know ancient popup ads, you probably agree with that web apps shouldn't be able to override some important things.)

Comment 8

[kingsleyarchibald]

https://jsfiddle.net/de3antzv/

This blocks SH+F10 and Alt+F4 in Firefox 47.0.2 but does not block SH+F10 or Alt+F4 in Firefox 62.0.
If Alt+F4 is "just handled by OS" why does this fiddle block Alt+F4 on Firefox 47.0.2?
(By the way, on Chrome 68.0.3440.106 it blocks SH+F10 but not Alt+F4: so maybe SH+F10 not blocking is a bug in the latest FF or my way of blocking is wrong? Please have a look if you have time)

As to whether FF should allow web apps to block these hotkeys, I understand that you guys are trying to develop for the general populace, and that apps can do some really annoying things in the JS. But by ignoring the preventDefault/stopPropagation/stopImmediatePropagation for only certain cases, the Javascript interface becomes inconsistent with what is expected. For my personal case, my app needs every hotkey possible (I realize most people do not need this of course!) and it sucks for me that it used to work, but it doesn't anymore. Most users do not know what Alt+F4 does and I think most who do know how to handle annoying popup ads in another fashion anyway. So no, I do not agree that web apps shouldn't be able to override Alt+F4 or SH+F10.