Allow disabling Shift+right click
Categories
(Core :: DOM: Events, enhancement)
Tracking
()
People
(Reporter: 123lichessaccount, Assigned: gregp)
References
Details
Attachments
(1 file)
Steps to reproduce:
Go to a website that uses shift+right click for some functionality and doesn't allow to overwrite this. Try to use the default website's functionality by holding shift and right clicking.
Actual results:
Firefox shows the context menu. Not possible to use the website's functionality.
Expected results:
There should be an option to disable this in the about:config. This would allow to use websites that implement Shift+right click for something and don't allow to overwrite it.
|
||
Comment 1•2 years ago
|
||
Setting this as a NEW enhancement so the engineering team could have a look and decide if they take it into consideration or not. Also, moving this to Core:: XUL - if this is not the right component please move it to a more appropriate one.
Thanks!
|
|
||
Comment 2•2 years ago
|
||
Forgot to set the component, setting it now.
|
||
Updated•1 year ago
|
Actually this bug is really important to fix, I had to ditch Firefox to play an RTS game that cannot function properly on Firefox because of this.
There is the affected game website: https://littlewargame.com/
A config option in about:config would have allowed me to continue using Firefox for this, but it seems there is nothing of that sort.
I really want to switch back to Firefox to play this game, but I just currently cannot do that without ruining my gaming experience.
I'm ready to pay directly with real money to get this issue fixed.
|
Assignee | |
Comment 4•1 year ago
|
||
|
||
Updated•1 year ago
|
|
|
Assignee | |
Updated•1 year ago
|
Pushed by gp3033@protonmail.com: https://hg.mozilla.org/integration/autoland/rev/2ac0f0381525 Allow disabling Shift+Right Click force-opening the context menu r=emilio
|
||
Comment 6•1 year ago
|
||
| bugherder | ||
|
||
Comment 7•1 year ago
|
||
This might be worth calling out in the Fx117 relnotes. Feel free to nominate by setting the relnote-firefox flag to ? if you agree.
|
|
Assignee | |
Comment 8•1 year ago
|
||
Release Note Request (optional, but appreciated)
[Why is this notable]: New pref which improves compatibility with websites that use shift+right click
[Affects Firefox for Android]: Maybe? I haven't tested it.
[Suggested wording]: Some web pages disable the context menu, which can limit the options available to users. Firefox enables users to bypass this restriction by pressing shift and right-clicking to force the context menu to show. However, this may interfere with some web pages that have legitimate purposes for blocking the context menu on shift+right click. To address this issue, we have added a new preference: dom.event.contextmenu.shift_suppresses_event. Users can toggle this preference to respect the web page’s choice of blocking the context menu on shift+right click, if they prefer.
[Links (documentation, blog post, etc)]:
|
||
Comment 11•11 months ago
|
||
I am curious, why was this issue solved by adding a new about:config pref, and not by allowing the web page to use either event.stopPropagation() or event.preventDefault() on contextmenu/mouse events?
In Chrome it seems to work that way, and playing littlewargame on Chrome works as expected, while on Firefox requires the end user to activate an about:config to get the proper expected site UX. That feels incorrect?
|
||
Updated•11 months ago
|
|
||
Comment 12•10 months ago
|
||
(In reply to Jukka Jylänki from comment #11)
I am curious, why was this issue solved by adding a new about:config pref, and not by allowing the web page to use either event.stopPropagation() or event.preventDefault() on contextmenu/mouse events?
Some websites blocks context menu without good reasons. E.g., only for preventing "copy" of selected text, websites may block context menu even though context menu may have more important features for users.
In Chrome it seems to work that way, and playing littlewargame on Chrome works as expected, while on Firefox requires the end user to activate an about:config to get the proper expected site UX. That feels incorrect?
That's a dilemmna between reasonable use cases vs. illegal use cases. If we could find a good way to detect the reasonable cases, we could prevent to block the intention of the website.
|
|
||
Comment 13•10 months ago
|
||
Some websites blocks context menu without good reasons. E.g., only for preventing "copy" of selected text
Don't websites already routinely prevent copying selected text? It is odd to draw the line only at shift-right click for preventing copy, when it is already a perfectly valid use case to make text non-selectable to begin with? ( https://stackoverflow.com/questions/2310734/how-to-make-html-text-unselectable )
If we could find a good way to detect the reasonable cases, we could prevent to block the intention of the website.
Could this be started by allowing preventing default action on shift-right click when mouse is on top of a canvas element? That would cover all web games cases.
|
|
||
Comment 14•10 months ago
|
||
(In reply to Jukka Jylänki from comment #13)
Some websites blocks context menu without good reasons. E.g., only for preventing "copy" of selected text
Don't websites already routinely prevent copying selected text? It is odd to draw the line only at shift-right click for preventing copy, when it is already a perfectly valid use case to make text non-selectable to begin with? ( https://stackoverflow.com/questions/2310734/how-to-make-html-text-unselectable )
No, it's not the point. The problem is, only for preventing some feature in context menu, disabling context menu is overkill.
If we could find a good way to detect the reasonable cases, we could prevent to block the intention of the website.
Could this be started by allowing preventing default action on shift-right click when mouse is on top of a canvas element? That would cover all web games cases.
May be, may be not. Somebody needs to work on it, implementing it only in the nightly channel first, then, collect feedback, finally, ship it if it works well.
Description
•