User control over grabbing of key browser controls (shortcuts/right click)

[Stilez]

This suggestion aims to give nice, and sufficient, but simple-to-add, control by users over websites that usurp key shortcuts or right click menu in an unhelpful way, as seen by the user.

I think there's an argument that whatever a web page might do, core browser-level controls that users rely on shouldn't be easily usurped by web pages, without giving a user some way to control whether they're happy about it doing so.

What I'd like to see is a way to specify keys that the website can't override, and how right-click usurp should be handled. The UI and code can be made extremely simple by focusing on the basic aim: "ringfencing" key user controls over the browser, as seen by the individual user.

• Keyboard shortcut protection: Because the aim is to protect key controls, if the user wants keys such as ctrl-tab or ctrl-T reserved for browser functions, we can assume at the start that it's probably all-or-nothing, so we don't have to worry about "per website". (Or at least that's an enhancement for someone so inclined). We just need to provide a means to enter a string/list of non-usurpable keys.
• Right click protection: Add a simple 3 state option: right click controlled by browser (no override), controlled by website (can override) or always includes browser items (can add new options, can't remove browser-set options).
  The latter would be a really nice default, meaning that web pages like google maps can add new options for "directions to/from here", but can't remove existing ones. Even an unhelpful website probably will be manageable, if it can't remove any user-set right click options.

[yami_]

You can already disallow JS to change or disable context menu: dom.event.contextmenu.enabled.

[Stilez]

You can already disallow JS to change or disable context menu: dom.event.contextmenu.enabled.

You can, but it's really problematic in practice. Because your only option is enable/disable globally, means that disabling for the many troublemakers you don't visit often, also means disabling for the few you use a lot and really need it to work.

The suggestion presented comes from asking if there's a better way to avoid that conflict, than per-website control. It turns out that there is - adding an option to it that blocks removal of browser/extension created context items, but doesn't affect addition/removal of other context items. So sites that annoyingly remove useful context items can't, but sites that provide and manage additional context menus can still do so.

This seems simple.enough and useful enough to be a valuable workaround for the current dilemma.

[SamSpeed]

I agree with the sentiment of this thread. It seems that some web developers think that their website is an application (or app) in and of itself. That ain't right. The application I am running is Palemoon -- the website is just a website.

The idea of having

... a simple 3 state option: right click controlled by browser (no override), controlled by website (can override) or always includes browser items (can add new options, can't remove browser-set options).

is to me very appealing.

Thinking algorithmically that third option might be accomplished simply by set manipulation -- let the website modify the menu freely and at the point of modification, re-apply the standard browser menu items leaving new items intact.

[Stilez]

Thinking algorithmically that third option might be accomplished simply by set manipulation -- let the website modify the menu freely and at the point of modification, re-apply the standard browser menu items leaving new items intact.

I'd be a bit cautious of this appealing approach, simple because browser context menus can be dynamically modified by extensions - they're far from a standard list, and perhaps in edge cases it could cause pathological situations if an extensions changes to the context menu is affected in some sense by the web content/page itself. Would it be easier to add a boolean to the context menu structure, to flag "context menu item was set from within chrome/extension", and silently ignore removal/modification attempts by non-chrome, where that bit is set?

(It would require distinguishing chrome vs nonchrome origin for calls to the relevant API, but presumably there's a way to distinguish which context/privilege level we're in)

[Stilez]

Another keyboard example that might be important to.some users - people with visual impairment might need keys like tab to work as expected, to navigate between fields, or other keys to manage screen readers/element focus/navigation. Being able to tell the browser "don't let keys in <list> be overridden" could have especial value for them. (Thinking about things like tab usurp for block indent/outdent in an online text area field, which are usually benign, it might be a real problem to some users, but very valued by others as a useful shortcut).

[therube]

permissions.default.shortcuts

Untested in PM, using about:config to disable Firefox shortcuts?

[firefoxed]

Firefox 58 seems to have a NEW option that seems to do that: Block "Override Keyboard Shortcuts"



This is discussed on this StackExchange thread.

I wonder if PaleMoon is considering something similar?
By the way I would throw in things like modifying "Ctrl - Click" behavior in the same basket.