Closed Bug 1325758 Opened 7 years ago Closed 7 years ago

Ability to specify insertion point for contextMenu item or submenu

Categories

(WebExtensions :: Untriaged, enhancement, P5)

Product:
WebExtensions
Component:
Untriaged
Type:
enhancement

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: bugzilla, Unassigned)

References

Details

(Whiteboard: [design-decision-needed] triaged)

Attachments

(1 file)

Screenshot of current behaviour
21.45 KB, image/png
Details 
With a XUL add-on it's possible to specify where a menu item should be inserted on the context menu, i.e. using Node.insertBefore() or Node.insertAfter(). 

With WebExtensions, it seems as though an add-on's context menu item (or items, via a submenu) will be placed in arbitrary order with relation to other add-ons at the bottom of the context menu. 

I don't think this presents a particularly brilliant user experience; it might be fine for something like LastPass, which isn't really being used contextually anyway, but I would prefer to be able to add my "Search for" item below the in-built function - please see attached screenshot.

My current XUL add-on (by default) replaces the in-built menu item completely[1], but I assume that's going to be a total no-no in the new world.


[1]: http://www.basson.at/images/addons/contextsearch.png
Whiteboard: [design-decision-needed] triaged
(In reply to Ben Basson from comment #0)
> My current XUL add-on (by default) replaces the in-built menu item
> completely[1], but I assume that's going to be a total no-no in the new
> world.
> 
> [1]: http://www.basson.at/images/addons/contextsearch.png

Also something like this: https://addons.mozilla.org/firefox/addon/view-image-filename/
Giving extensions the power to decide how important they are over others doesn't seem a good user experience either.

Wouldn't it be better to give users control of what order they want the menus in? Like I might expect users eventually to have an ability to manage keyboard shortcuts.

At best I could see an extension being able to categorise themselves by function, however these menus are often complex and not as organised as that.
(In reply to Jonathan Kingston [:jkt] from comment #2)
> Giving extensions the power to decide how important they are over others
> doesn't seem a good user experience either.

My add-on has done this for literally a decade and has consistently had tens of thousands of active users, I've never once received a suggestion that I should have put it somewhere else on the menu. I mean, it's in the description of my add-on that it replaces the existing menu item, it probably couldn't have been more clear in terms of intent :-)

It sounds to me (correct me if I have misinterpreted) that your concern is that "bad" add-ons might do weird stuff on the context menu. 

Generally I would suggest that enforcing some kind of policy on something as trivial as this through code is not worth it. Add-ons are easy to add and remove, and people can remove add-ons that do stuff they don't agree with (as they _always_ have).

As you say, it would probably be prohibitively difficult to organise by function. Whether it's worth adding UI to manage the menu is questionable, but is also a different question from the one being asked in this bug.
My naive implementation would be to give each inbuilt context-menu item a unique ID and then an add-on could specify that it wants its context menu to be inserted before/after/instead of a certain inbuilt ID. If multiple add-ons specify the same ID, then the browser decides on the final ordering.

In the case of replacing an inbuilt-menu in that way, this could be integrated into the permissions dialogue by looking up the context menu entry corresponding to that ID: "This add-on wants to replace the "frob widget" context menu entry. Okay?".

(And maybe we can rethink bug 1294429 again?)
Hi Ben and Jan, this has been added to the agenda for the June 6 WebExtension APIs triage meeting. Would you be able to join us? 

Wiki: https://wiki.mozilla.org/Add-ons/Contribute/Triage#Archive

Agenda: https://docs.google.com/document/d/1pTNjK5i_8gHt3EeiUiu5KCUVeRcfwn7ybCPDBSx6CLM/edit#
This sounds like a good idea, but just in case it doesn't happen, at least make the order in the contextmenu consistent. Right now the entries get randomly shuffled, so I can't even get used to an order - it just changes all the time.
Flags: needinfo?(amckay)
I agree with sblask in comment 6, that the order should somewhat consistent. I've filed bug 1370735 for that.

The concerns we've got are: 
* many add-ons will want to be at the top and they will get into a fight about it
* the context menu is logically grouped and add-ons should fall into the logical grouping
* the logical group of the context menu eg: "Save Page, Save Page As.." is hard to figure out
* Firefox is going for consistent areas of the UI where we'd expose extensions too eg: this part of the context menu, this part of the tools menu, this part of the page action menu and anything straying from that gives me cause for concern

On the last point pinging Kev who's raised similar concerns on similar APIs in the past.
Flags: needinfo?(amckay) → needinfo?(kev)
I understand your concerns about ordering, although I feel that if this is a problem, it's a problem that already exists with the existing add-on ecosystem). 

If specifying ordering or insertion point is non-starter, would the idea of replacing an existing item be entertained (as described in comment 4) or is that also not something that you would be willing to entertain? Should I file that separately?
Sorry for not being able to make it to the triage meeting. While I accept that this has the potential for misuse, there still are legitimate use cases as well that would be hurt if no control at all over the menu position was available.

E.g. I currently use a few extensions that add image-related context menu entries (search image with Google's reverse image search, open image *in a new tab*) and its quite nice that those additional menu items are grouped together with Firefox's inbuilt menu items (show image, copy image address, etc.).

I also use an extension that modifies the inbuilt "Show (background) image" command to append the file name of the image in question to the menu entry.
A basic webextension implementation of that might or might not be blocked on bug 1215376, but that aside
- currently I wouldn't be able to override the inbuilt menu, so I'd have to add an additional menu entry just so I have somewhere I can show the filename
- I couldn't place that menu entry with the file name near the other inbuilt image-related menu entries, either (this bug)
- I'm not sure how this could end up being implemented, but if wanting to override both "Show image" and "Show background image" would count as providing more than one context menu, I'd also run afoul of the current limit of only one top-level context menu item per extension (splitting the extension just for that is possible but somewhat silly).

Of course a workaround to programmatic ordering would be allowing the user to customize the context menu, but because of how the menu is partially customised on the click target this would have its own share of difficulties.

(In reply to Andy McKay [:andym] from comment #7)
> The concerns we've got are: 
> * many add-ons will want to be at the top and they will get into a fight
> about it

If multiple add-ons want to be placed at the same spot, the browser will decide the final ordering. As for the abuse potential, this could also be covered semi-automatically during addon-review: Just maintain a list of "dangerous" context menu entries (i.e. inbuilt menu entries that by default appear at the top of the context menu and which would be attractive to less scrupulous developers) and if an add-on requests to be placed next to (especially above) such an entry, it'll get flagged for special review.

> * the context menu is logically grouped and add-ons should fall into the
> logical grouping

Unless that logical grouping consists of simply lumping all add-ons together in one spot, add-ons still would need some way of indicating where they would fit best into the grouping - although I guess your comment below answers that.

> * Firefox is going for consistent areas of the UI where we'd expose
> extensions too eg: this part of the context menu, this part of the tools
> menu, this part of the page action menu and anything straying from that
> gives me cause for concern

I see your reasoning behind this and yes, I accept that it would simplify things because there's simply no (or at least less) abuse potential to worry about.
At least on paper, grouping everything provided by add-ons together also has some logic to it, but at least personally I'd argue that add-ons appearing next to (or even instead of when it makes sense) inbuilt menu items if the add-on in question is actually extending or otherwise related to that functionality could be even more logical and lead to better usability than just lumping everything add-on provided together into a sort of "Here there be dragons"-category.
+1 for this feature. I was trying to rewrite using WebExtensions the "Close tabs to the left" addon[1], which is a must have for me.

In this case, I need to insert the "Close Tabs to the Left" item just above the existing "Close Tabs to the Right" item. Having it at the bottom of the context menu is just horrible.


[1] https://addons.mozilla.org/en-US/firefox/addon/close-tabs-to-the-left/
See Also: → 1385202
From a product standpoint there are a couple pieces that can make arbitrary placement challenging. The context menu is one of those bits of UI that isn't used by a large number of users (citation needed, and I'll dig that up depending where we go with this), but the consistency of what's provided as a default is important for the people who do.

The word abuse is used a lot in the discussion, but the big focus is a clear and consistent user experience, along with an equally clear policy on how a feature like this would be used. Abuse is something we'll run into and have to deal with, that's what policy is for, although programmatic enforcement of that is ideal (a goal). The approach in comment #2 and comment #8 (user decides if they wants something and where) is not something I'd consider as part of the API; it's more of a front-end customization question than something extension specific.

I like the idea of sensical ordering, and the idea behind the context menu is that you get a logical set of options for what you happen to right-click on. The examples presented here are good examples of that, and my main question is the effort it would take to manage and maintain, particularly as/if context menus change over time. 

There's a couple goals we're looking to hit:

- Default UI elements are presented
- Non-default elements add to/or complement user value
- Identification of non-default items is a nice to have
- No breakage on changes to Firefox (e.g. if the default context menu changes, there should be a clear path)
- Developers know the rules, or at least the outcomes

The extension-specific area is appealing because it hits all of the above, and doesn't include any menu-specific maintenance. My thoughts are we start with a predictable ordering, and identify use cases where positioning is important (biggies being tabs, selected text, and page), and consider what it would take to maintain them and go from there.   

(In reply to Andy McKay [:andym] from comment #7)
> * Firefox is going for consistent areas of the UI where we'd expose
> extensions too eg: this part of the context menu, this part of the tools
> menu, this part of the page action menu and anything straying from that
> gives me cause for concern
> 
> On the last point pinging Kev who's raised similar concerns on similar APIs
> in the past.
Flags: needinfo?(kev)
(In reply to Caitlin Neiman (http://pronoun.is/she) from comment #5)
> Hi Ben and Jan, this has been added to the agenda for the June 6
> WebExtension APIs triage meeting. Would you be able to join us? 
> 
> Wiki: https://wiki.mozilla.org/Add-ons/Contribute/Triage#Archive
> 
> Agenda:
> https://docs.google.com/document/d/
> 1pTNjK5i_8gHt3EeiUiu5KCUVeRcfwn7ybCPDBSx6CLM/edit#

What was the intent and the outcome of this meeting? Were any decisions made? Do extension developers now have everything they need to move ahead?
Flags: needinfo?(cneiman)
Severity: normal → enhancement
Priority: -- → P5
I am going to revisit this b/c i have been tracking screenshots on feedback pretty closely. 

We're getting a fair amount of complaints about inspect element being moved from the bottom of the context menu.

I have no opinion about whether we should allow add-on authors to register a specific location for their item, but i DO think it might make sense to move Inspect Element back to the bottom of the menu since it's a well worn work-path for our developers.

CF: https://bugzilla.mozilla.org/show_bug.cgi?id=1393108
Kev, could you take a look at the proposal in 1393108 for me? It seems like an easy win for developers.
Flags: needinfo?(kev)
Flags: needinfo?(kev) → needinfo?(mconca)
Hi Ben and Worcester12345, we're going to circle back to this one at the October 3 WebExtensions APIs triage. Would either of you be able to join us? 

Agenda: https://docs.google.com/document/d/1X5RmNq2tGC5Aw3npIKqxB2vhnVhg9uOoXh2TggduTPU/edit#

Wiki: https://wiki.mozilla.org/Add-ons/Contribute/Triage#Next_Meeting
Flags: needinfo?(cneiman)
(In reply to Caitlin Neiman (http://pronoun.is/she) from comment #17)
> Hi Ben and Worcester12345, we're going to circle back to this one at the
> October 3 WebExtensions APIs triage. Would either of you be able to join us? 
> 
> Agenda:
> https://docs.google.com/document/d/
> 1X5RmNq2tGC5Aw3npIKqxB2vhnVhg9uOoXh2TggduTPU/edit#
> 
> Wiki: https://wiki.mozilla.org/Add-ons/Contribute/Triage#Next_Meeting

I don't think I would be of much help. I am here to support Ben, as I like using his extension(s). Once he has these up and testing, I can work with him, and he can report back here if issues.
Flags: needinfo?(mjaritz)
Flags: needinfo?(mixedpuppy)
First, I'm not a big proponent of doing anything here.  Anything we do will add complexity.  As well, if an extension has more than one menu we group them (I believe appropriately) into a submenu which makes placement a bit pointless.

If we are to do something, my suggestion around this is to form set of loose groups for context menu types.  If you look at 

http://searchfox.org/mozilla-central/source/browser/base/content/browser-context.inc

you'll see that is roughly how the menus are currently inserted into the ui.  In order it appears to be:

navigation
spell checking
links
 - open
 - bookmark/save/copy
media
images/video
page operations
clipboard
frames
view source/info
login
inspector

We could add empty placeholder elements at the end of each logical grouping with a contexttype attribute, and insert extension context menu's at that point.  So an extension that does image operations, could have its menu placed near other image operations.

creating a menu with an additional attribute could look like:

menus.create({contexttype: "image-operations", title: "Send to iPhoto", ...});

which would insert the new context menu into our placeholder:

<emptyelement contexttype="image-operations">
<menuitem id="some-extension-menu" label="Send to iPhoto"/>
</emptyelement>
Flags: needinfo?(mixedpuppy)
(In reply to Shane Caraveo (:mixedpuppy) from comment #19)
> As well, if an extension has more than one menu we group
> them (I believe appropriately) into a submenu which makes placement a bit
> pointless.

or at least I think we do...
(In reply to Shane Caraveo (:mixedpuppy) from comment #19)
> if an extension has more than one menu we group
> them (I believe appropriately) into a submenu which makes placement a bit
> pointless.

I disagree. You're still allowed one context menu entry per extension, not allowed to manually override the visibility or ordering of entries, and some people have quite a few extensions.

The more extensions one has, the more relevant this is.
Several good points have been made about the added value this feature could offer to extension developers, and there are some use cases where being able to specify the insertion point of a context menu item would be intuitive. However, we won't be proceeding with this change. Most of the salient points were captured in Comment 7 and Comment 11, but in summary, the need to preserve a consistent interface outweighs the potential benefits at this time.
Flags: needinfo?(mjaritz)
Flags: needinfo?(mconca)
Status: UNCONFIRMED → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
I'm very dissapointed to hear this. Together with the decision in bug 1294429, this basically completely ruins the user experience for extensions like Context Search X.
(In reply to Botond Ballo [:botond] from comment #23)
> I'm very dissapointed to hear this. Together with the decision in bug
> 1294429, this basically completely ruins the user experience for extensions
> like Context Search X.

Don't forget bug 1385202. Apparently it's random context menu FTW so far mozilla is concerned, with submenus to aggravate it.
(In reply to avada from comment #24)
> (In reply to Botond Ballo [:botond] from comment #23)
> > I'm very dissapointed to hear this. Together with the decision in bug
> > 1294429, this basically completely ruins the user experience for extensions
> > like Context Search X.
> 
> Don't forget bug 1385202. Apparently it's random context menu FTW so far
> mozilla is concerned, with submenus to aggravate it.

FTW? Is this the second meaning under "wiktionary"? Not sure what you mean by FTW here; or is it sarcasm?
"<thing> FTW" means "<thing> For The Win", so the meaning basically boils down to "apparently it's 'random context-menu ordering is wonderful' so far as mozilla is concerned, with submenus to aggravate it".
I want to add my support for this. I regularly used the "open in foreground tab" context menu entry but in a recent update it disappeared. I looked for a way to enable it again and found an plugin that added the entry back. Unfortunately, the plugin-added entry is at the bottom of the context menu, which is much less convenient. As a consistent Firefox user for over a decade, I am disappointed by the recent removal of user control over this browser. Instead of staking "the need to preserve a consistent interface", why aren't we talking about supporting user-driven interaction?
Following some tickets like this one gives the feeling that the people in charge from Mozilla can't really comprehend the user's needs. Sometimes it seems like just because they don't use some missing webextension feature they think there is no use-case for everybody else.
Stop patronizing your users. If an extension wants to add more than one menu-item at the top of the menu there is probably a good reason for that and some people who want this.
Product: Toolkit → WebExtensions
See Also: → 1370735
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: