Closed
Bug 976786
Opened 12 years ago
Closed 12 years ago
Add an option to disable HTML5 context menus
Categories
(Firefox :: General, enhancement)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: jaramat, Unassigned)
References
()
Details
Attachments
(1 file)
|
15.60 KB,
image/png
|
Details |
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0
I've encountered people who don't like HTML5 context menus feature and would like to turn it off, because it may change their normal workflow with mouse (when fast-clicking RMB and Back/Forward). However, there is no way to get rid of this feature.
Therefore, I propose a few changes that may possibly satisfy these users.
1. Add a config switch to enable/disable HTML5 context menus
People who don't like this feature could simply turn it off. After all, since none of other browsers support it, it's hardly something that could break websites' basic functionality.
(boolean) html5.contextmenus.enabled
- true - enable HTML5 context menus (enabled)
- false - disable
2. (Add a config switch to) Move HTML5 menuitems to the bottom of the context menu
HTML5 menu items are currently added to the top of the menu, which may surprise some people, as they may expect classic "Back", "Forward", and "Reload/Stop" commands there. Moving the HTML5 menuitems would likely cause far less confusion new users.
(boolean) html5.contextmenus.place_at_top
- true - place HTML5 context menus at the top of the context menu (default, nothing changes from current behavior)
- false - place at bottom
3. If HTML5 context menu items present, open context menu with a vertical indentation
Context menus with HTML5 menuitems would open a few pixels higher from mouse cursor, as seen in the attachment
4 [review]. Combine previous suggestions
(integer) html5.contextmenus
- 0 - disabled
- 1 - enabled, place at top (default)
- 2 - enabled, place at bottom
- 3 - enabled, place at top, open context menu with indentation
5. Assign classnames to HTML5 menuitems
Currently, HTML5 menuitems don't have any class name nor unique ID, making it impossible for people to just hide these menu items with userChrome.css. Assigning these menu items their class name would make this possible (example: menuitem.pagemenu {display: none;}).
Comment 1•12 years ago
|
||
We need a higher standard that "I don't like this" when considering usecases. We're not going to add options for random things unless it's something that affects a sizable fraction of users, or the impact is high.
#3 is an interesting idea, as it helps preserve consistent placement of standard items (relative to the pointer). Although this won't help with cases were placement restrictions disallow it (eg, clicking at the top/bottom of the screen). And doesn't help with the mobile case (which is one of the main reasons for allowing this), where the UI is presented as a standard menu/selection overlay.
I think the best solution is for an addon to provide this functionality. #5 would be one way to do this, but I think it should already be possible by overriding toolkit/modules/PageMenu.jsm to make that a no-op. It could also listen for |contextmenushowing| and kill the added items then.
Now that I look, there are already two things in place:
* Shift-rightclick will display a context menu without page-supplied items
* Page-supplied items are added with a |generateditemid| attribute.
It think these adequately cover the need.
Status: UNCONFIRMED → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•