Open Bug 379210 Opened 17 years ago Updated 3 months ago

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

Categories

(Core :: DOM: Events, defect, P5)

Product:
Core
Component:
DOM: Events
Type:
defect

Tracking

()

People

(Reporter: csthomas, Unassigned)

References

Details

dom.event.contextmenu.enabled should be false by default
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
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.
Does it even make sense to let websites block the context menu by default? I don't think so.
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.
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.
Or, another solution would be turning context menu hack attempts into infobars when dom.event.contextmenu.enabled is false.
> 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.
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.
Blocks: useragent
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.
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).
See Also: → 854401
https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven't been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.
Priority: -- → P5
Severity: normal → S3

We now have year 2023, and HTML5 apps with their own context menu haven’t really manifested. As popular examples go, it’s still largely Google Docs. This functionality likely also underused because these UX concepts don’t work on mobile. You either cannot right-click at all there, or it is too complicated to be really usable. So the common concept is rather some sort of a hamburger button providing access to additional functionality, either on a general basis or per item.

Which brings us back to the question: should this be on by default? Also: Firefox has an extensive per-website permission mechanism now which could be leveraged here. It doesn’t even need a new API, the permission prompt could show up as an icon in the address bar the first time a website attempts to prevent the context menu. This would allow the few websites using this feature legitimately to continue working as before.

(In reply to Wladimir Palant from comment #14)

We now have year 2023, and HTML5 apps with their own context menu haven’t really manifested.

Citation needed :)
Half of my pinned tabs have a custom right-click handler. But I don't think there's merit in discussing personal experiences or preferences, because the context menu event is part of the web platform per the UI Events specification.

If you want to argue for removal, I suggest you have that conversation at the standards body level.
Doing this successfully, is no easy feat though. Even if we knew this was completely unused in 99.9% of all web pages (we don't). You'd still be required to gather sufficient data and get buy-in from more than 2 browser engines.

Reflecting on the diverse perspectives shared in this thread, it's evident that the balance between user control and web application functionality is a nuanced issue. The primary concern seems to be maintaining a user-friendly experience while enabling web applications, like Google Docs, to utilize custom context menus effectively.

Considering the evolution of web standards and user expectations, perhaps a middle-ground approach could be more beneficial. Instead of a binary setting for dom.event.contextmenu.enabled, what if we introduce a more dynamic solution? For instance, a browser setting that allows users to easily toggle the behavior per site. This way, users retain control over their browsing experience, deciding when to allow custom context menus on a case-by-case basis.

This approach respects the principle of user autonomy over browser functionality while acknowledging the legitimate use cases for custom context menus in modern web applications. It also aligns with the growing trend of personalized browser experiences, where users have more direct control over how they interact with web content.

I would love to hear thoughts on this idea, especially considering the technical feasibility and user experience implications. and i encountered a bug while trying to access this URL: https://miwam.io/

You need to log in before you can comment on or make changes to this bug.