dom.event.contextmenu.enabled should be false by default (don't let web pages interfere with context menus by default)

NEW
Unassigned

Status

()

Core
DOM: Events
11 years ago
4 years ago

People

(Reporter: Chris Thomas (CTho) [formerly cst@andrew.cmu.edu cst@yecc.com], Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

dom.event.contextmenu.enabled should be false by default

Comment 1

11 years ago
Moving to core and changing to All/All since this is also an issue in Firefox.
Assignee: general → events
Component: General → DOM: Events
OS: Windows XP → All
Product: Mozilla Application Suite → Core
QA Contact: general → ian
Hardware: PC → All

Comment 2

11 years ago
Why are you proposing this change?
Summary: flip dom.event.contextmenu.enabled → dom.event.contextmenu.enabled should be false by default (don't let web pages interfere with context menus by default)
(In reply to comment #2)
> Why are you proposing this change?

Because I hit a site that blocked my context menu and it annoyed me.

Comment 4

11 years ago
Does it even make sense to let websites block the context menu by default? I don't think so.

Comment 5

11 years ago
I think making this change would be bad overall.  While there are some sites that annoyingly block the context menu in an effort to "protect" images from being saved, there are also sites that override context menus in useful ways.

This change would be a permanent blow to the usability of sites like Google Docs & Spreadsheets, but it would only temporarily shift the state of the "misguided webmaster vs. visitor" situation.  (Sites that don't want visitors to copy images will switch to Flash, overlay a transparent image on top of the image of interest, split the image into quadrants, or swap out the image when it gets focus.  They'll continue to be defeated by users who know how to take screenshots.)  

Also, I think web apps are becoming more common and more important relative to sites run by the kinds of misguided webmasters who would attempt to disable context menus as a form of DRM.

Comment 6

11 years ago
Then we need a key combo or such (like alt+shift+right click) for opening a context menu without throwing a right-click event. The result: web apps w/right click used will still function, while sites that throw "Copyright protection!" or something similar can be alt+shift+right-clicked th get a context menu without triggering the script.

Comment 7

11 years ago
Or, another solution would be turning context menu hack attempts into infobars when dom.event.contextmenu.enabled is false.

Comment 8

11 years ago
> I think making this change would be bad overall. (...) there are also sites 
> that override context menus in useful ways.
> This change would be a permanent blow to the usability of sites like Google
> Docs & Spreadsheets
> (...) such as marking a mine in Minesweeper or showing a context
> menu for a spreadsheet. from bug 299424 comment #7

> Also, I think web apps are becoming more common and more important relative to
> sites run by the kinds of misguided webmasters who would attempt to disable
> context menus as a form of DRM.

Jesse, 
there is now a widely accepted, recognized and acknowledged principle among accessibility and usability groups which states that web content development sandbox must exclusively apply to (and should be delimited by) content area only, to non-chrome elements and not to normal, standard browser functionalities and normal, standard chrome elements. If that Google Docs & Spreadsheets can not work without a custom contextmenu, then it is not accessible, it is not usable by definition and it is not a well designed web application to begin with.

Right-click contextmenu is even a platform os standard feature, just like a scrollbar, menubar, toolbar, etc.

Users should have absolute veto power over web-based applications and webpages which try to disable chrome and/or browser functionalities and they should be able to apply their veto power easily, conveniently. Users should not have 
- to post in forum support newsgroups, 
- to search forum newsgroup archives and knowledge base articles, 
- to spend hours reading helpfiles, FAQs, support (online or web-based) documentation, 
- to search+find+read+understand how to create and edit an user.js
file,
- to find, to understand and to select complex or long multi-level user prefs UI,
- to file enhancement request in bugzilla bugfile, 
- to send emails to webmasters,
- to find and figure out all kinds of possible prefs, settings related to about:config, 
- to spend non-sensical efforts

just to restore normal, standard right-click contextmenu.

There are a lot of Firefox addons extensions which already add items in right-click contextmenu.

My 2 cents
Assignee: events → nobody
QA Contact: ian → events
Now the option was removed from the options dialog. If we flip the default, most users will not be able to enable customized context menus even if they want. Many sites (including YouTube and SkyDrive) are using customized context menus these day.

Comment 10

4 years ago
The option was removed as part of the patch in bug 851702.  Gerv's comment in that bug seems to match my reasoning in comment 5.

Updated

4 years ago
Blocks: 86194
I'm afraid almost no one cares about the HTML5 context menu... It is available even if the contextmenu event is disabled and it will not limit users' power.

Comment 12

4 years ago
I'm against disabling right-click (per the reasons above). In the long run, websites should use HTML5 context menus (though their UX could be improved, see e. g. Bug 705292), though the current implementation needs to be updated (Bug 897102) first. If and when websites use HTML5 context menus more often, the pref can be set to false (however, switching this pref may drive websites to rely on HTML5 context menus more often, so that's something we may want to consider after Bug 897102 is fixed).

Updated

4 years ago
See Also: → bug 854401
You need to log in before you can comment on or make changes to this bug.