1294429 - support more than one contextmenu entry in root menu

Status: RESOLVED WONTFIX

(WebExtensions :: Frontend, defect)

Description

[TheRave]

User Agent: Mozilla/5.0 (Windows NT 10.0; rv:51.0) Gecko/20100101 Firefox/51.0
Build ID: 20160810030202

Steps to reproduce:

If we setup the contextmenu entries we are forced to place all entries under the addon name submenu if we have more as one entry in the context menu.



Expected results:

We should have the possibility or a separate flag to place more as one item in contextmenu root without to find them later as child in a submenu.

Addon developers should be free to decide the best position for their menu entries.

This should be an advanced functionality in opposite to the chrome browser behavior.

Comment 1

[Andy McKay]

There's a balance that we are trying to maintain with WebExtensions in that any change in the user interface should be clearly attributable to an extension. We felt it made sense to follow Chrome for this choice because it allows users to see which extension has caused the user interface to change in Firefox.

Having everything under one sub-menu based on the add-on name allows this to happen.

Comment 2

[TheRave]

Is the origin of the menu point not self explained by the menu point self? Everyone which installs a addon should know which addon is responsible for this menu point.

What is if you have only one menu point in your addon? Then you have no submenu with extension name and the name of the context menu item gives in case of also no information about source of which addon. Sorry, this argument doesnt match.

My main intention as user is to get the functionality as fast as possible without surfing thought more sub menus as necessary. This is also common known as usability. I have already own submenus if it is necessary.

Addon developers should cascade their menus self if its wanted. You can keep the chrome behavior as standard to have it chrome "nice", but we should have the possibility to override this.

Comment 3

[debiedowner]

I really hope that Mozilla will reevaluate this before 57 is rolled out. I really depend on add-ons that use this feature, most prominently Context Search X ( https://addons.mozilla.org/en-US/firefox/addon/context-search-x/ ). I use the context menu searches very often, for translations and for looking things up; and having the search engines I use frequently outside of submenus expedite this, both using the mouse, and more importantly, the keyboard. For example, after right click, the access key 'g' searches on Google, 'w' searches on Wikipedia, 'i' on imdb, 'y' on Youtube, 'e' on etymological dictionary, 'f' on French dictionary, 'o' on Oxford dictionary and so on, for a few other search engines that I use often. (Infrequent ones can be accessed from a submenu or I can just copy and paste in a new tab for those). Having this restriction on extensions would make such an add-on impossible.

With this restriction, the behavior I like would actually still be possible, but made unnecessarily difficult: I will have to install a WebExtension for every single search engine that I like to use outside submenus. I currently have 10, so 10 extensions, instead of the single add-on I use. Maybe I can find such extensions for popular search engines, like YouTube, but I hardly think they will be available for more minor engines that I need very frequently, like the French dictionary I use. Even if I find extensions for every single one, I won't be able to organize them as I like, order them, change their names, access keys, etc, as I do with Context Search X, I will be stuck with whatever the extension developer wrote. And if I want to change an engine with another one at some point, search for an extension starts again. Why does Mozilla want to make users go to such great pains? I mean, there may be a point in moving away from to XUL add-ons to WebExtensions to make them more stable; but there is absolutely no technical reason to place such heavy restrictions on extensions. Mozilla promised to make WebExtensions as capable as possible, more so than Chrome, and indeed, more capable add-ons have always been the strength of Firefox; it is very disappointing to see that Firefox might adopt this nonsensical restriction of Chrome. If we don't want extensions with multiple context menu entries, we are free not to install them (add a permission field for that if you like), but let us make that choice.

Comment 4

[debiedowner]

Also, what's funny is, any website that I go to can add as many context menu entries as they like, without my permission, as in here https://bug617528.bugzilla.mozilla.org/attachment.cgi?id=554309 . It makes no sense to me that strangers are allowed to modify my browser's behavior when I am visiting their site, but I, the user of the browser, am not allowed to do that, even if I give explicit permission.

I am already disappointed that I probably won't be able to change the access keys of default context menu entries (this allowed me to assign access keys to search engines that made intuitive sense even if they were taken by default menu entries), but I figured I would just have to live with non-intuitive access keys for search. But not having those entries for search at all? Why would you do that?

Comment 5

[TheRave]

I have an addon for a webserver based helpdesk software which adds to a inputfield for emailadresses on the "to:" field context menus entries to move already entered email addresses fast to "cc:" field or "bcc:" field. You know it there are 2 entries now and a "submenu" which nobody needs.

Comment 6

[Frédéric Wang (:fredw)]

For your information, my MathML Copy add-on (400-450 users) used to add two "copy mathml" and "copy annotation" items. Now both are in an additional submenu, which makes copy operation a bit inconvenient for users. See https://github.com/fred-wang/webextension-mathml-copy/issues/7

Comment 7

[debiedowner]

Funnily, I guess a workaround could be dividing the add-on into two extensions, with a warning "If you want this extension to work, you need to install this other extension as well." - "Well, why can't you combine them into a single extension?" asks the user. "Because Mozilla wishes it so, for... reasons."

I guess whether it could work depends on how interdependent the two menu commands are and how much interaction Webextensions allow between extensions, if any. I can see Context Search X working this way though; I would need to install "Context Search X 1", "Context Search X 2", "Context Search X 3", ... "Context Search X 15" as separate extensions from AMO in order to add multiple search engines to context menu. (Or maybe I can install the same extension multiple times? Would that even be possible?) I think the logos of search engines would still not be allowed in this case, because another needless limitation Mozilla decided to impose is menu items must have the same logo as the add-on itself, but it is a more minor annoyance for me if I could have them outside the context menu.

Comment 9

[TheRave]

There was yesterday a funny discussion in IRC WE channel about objective valid reasons for wontfixes of bugs like this one. Its a good point of course. After the entire monologues here, its time to let us know more about this reasons.

I can throw already the next good reason into this round which leads comment 1 into ad absurdum.
Every simple webpage can place more as one context menus entry into Firefox context menu root in opposite to a web-extension!

Comment 10

[Geoffrey De Belie (Smile4ever)]

(In reply to Andy McKay [:andym] from comment #1)
> There's a balance that we are trying to maintain with WebExtensions in that
> any change in the user interface should be clearly attributable to an
> extension. We felt it made sense to follow Chrome for this choice because it
> allows users to see which extension has caused the user interface to change
> in Firefox.
> 
> Having everything under one sub-menu based on the add-on name allows this to
> happen.

A tooltip which is visible to the user when hovering above the item would also allow this to happen. Furthermore, this is a much requested feature by many users of many WebExtensions.

Comment 12

[Botond Ballo [:botond]]

As a heavy user of Context Search X, I agree with what :debiedowner said in comment 3. This restriction seems silly and gratuitous.

(In reply to Andy McKay [:andym] from comment #1)
> any change in the user interface should be clearly attributable to an
> extension

I'm sorry, but I don't find this argument convincing at all. I think we should be able to assume a reasonable level of competence and good faith from extension developers (that they will give their context menu items labels that are clear and not misleading), and a basic level of competence from users (that, given clear labels, they can figure out what WebExtension they belong to).

Comment 13

[TheRave]

Practically all arguments of the devs are showed to be nonsense followed by no responses through the decision makers.
As resume, it is so simply as it is. They do not want this. We addon developers have sadly no voice in their rows and they can do whatever they want. More comments here will nothing change, until they self would need such a future.

Comment 14

[Timvde]

> any change in the user interface should be clearly attributable to an extension.

Would it be enough to force the extension icon for each entry?

Comment 15

[Sean Ryan]

I'm yet another post-Quantum miserable Firefox (non-developer) user due to this absurd restriction preventing extensions from adding multiple entries to the context menu. I too find my browsing experience frustratingly slowed by being forced to go to a sub-menu for context search entries which I use constantly.

Surely there's a much smarter way to address the issue of users confused by changed context menu entries? E.G. Have a fixed permanent Firefox-owned context menu entry "Extensions that amended this menu..." which will lead the user to a panel outlining the add/amend/delete actions from extensions - potentially with a further choice next to each to uninstall/disable that extension or guidance text and a link to about:addons/extensions for the uninstall/disable.

Comment 16

[caxisef]

Is it still a thing? Because of this nonsense I had to split my extension into 3 separate extensions. It is ridiculous!

Comment 17

[joe]

This is a huge bummer. Would just like to add my two cents... it'd be really great to see this fixed.

I've been exploring ways to restore the old "Close Tabs to the Right" and "Close Other Tabs" context menu behavior seeing as v78 needlessly grouped them into a submenu.

I finally decided to write an extension to re-add these items to the root of the context menu, only to discover that they automatically get grouped into a submenu themselves. And then I see that people have been voicing their dissatisfaction about this for 4 years now.

I could split it into multiple extensions, but then I'll run into inconsistent menu item ordering as described in this 3-year-old issue: https://bugzilla.mozilla.org/show_bug.cgi?id=1370735

What a nightmare. Just encountering one issue after another, all so that I can restore a behavior that never should have changed to begin with.

Comment 18

[hoxegin232]

I came here for exactly same reason joe :(

This is an accessibility issue for me - more mouse-clicks == more pain.

I don't mind FF nesting stuff in context menus by default, but ffs let me mod it back.

Comment 19

[hoxegin232]

I've had to do an ugly hack - have one context menu entry (so it appears at top), and then handle {left/middle/right} click to {close tabs to left/close other tabs/close tabs to right}.