942628 - context-menu module has no API to insert items at an arbitrary index

Status: RESOLVED INCOMPLETE

(Add-on SDK Graveyard :: General, defect, P3)

Description

[nodeless]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:28.0) Gecko/20100101 Firefox/28.0 (Beta/Release)
Build ID: 20131123030208

Steps to reproduce:

The context-menu module can only add menu items at the bottom of the context menu. There should be support in the API to insert at an arbitrary index (e.g., the top of the context menu).

Use case: a developer creates an add-on that has a new menu item called "Open Link In New Panel". The ideal UX is for this menu item to be positioned next to the existing "Open Link In New Window" item.

Being able to use the IDs at https://developer.mozilla.org/en-US/docs/FirefoxOverlayPoints/Menus to determine position in the context-menu would work, and I think is what the old style firefox extension API provides.

Immediate concerns I can think of:
1) There's code in context-menu that groups all of an addon's menu items together, so that multiple addons don't get their items jumbled. That logic could stay, but anything that uses the new API to explicitly position itself would not be considered in the grouping process.

2) The context-menu docs say "menu items are displayed in the order created". Does that provide sufficient flexibility, such that we should not support the ability for an addon to position items relative to its own items (i.e., this new API would only be used when an addon wants to position one of its menu items next to a built-in menu item)?

3) How will this interact with the extensions.addon-sdk.context-menu.overflowThreshold preference?

Comment 1

[Erik Vold [:erikvold] (please needinfo? me)]

I've always wantd this too, not sure how hard/complicated it would be though.

Comment 2

[Jeff Griffiths (:canuckistani) (:⚡︎)]

Darrin - we're wondering if you have any opinions on this, particularly if we are more restrictive than html5's context menu support.

Comment 3

[Darrin Henein [:darrin]]

I can't think of any UX concerns with allowing arbitrary positioning... arguably the only concern would be discoverability (where current add-on menu items are easy to identify at the bottom of the menu). Presumably the user would know which add-ons they are expecting to see and could identify them anywhere in the list? I think in this case there is no strong case for being restrictive.

Comment 4

[nodeless]

Patch: https://github.com/nodeless/addon-sdk/commit/d83587b50e321d7a289f46c9319af3e79c9b50c1

This is just a quick prototype I made, but it works for my basic use case (position one element explicitly above "Open in new tab" item, and let one element be automatically positioned by context-menu). It probably has bugs, and obviously needs a bunch of new tests/documentation.

What should be done about moving userPositioned items into the overflow menu? If an addon added a bunch of userPositioned items into the context-menu, it would be nice if the user had a facility to force that addon's items into the overflow menu (otherwise the user's only option is to remove the addon). Could we add a new preference extensions.addon-sdk.context-menu.addonsToOverflow which would be an array of strings identifying which addons to force into the overflow menu? I think we could also leave it up to each addon itself to provide such settings to users ("Display context items in overflow menu?"), but it would be nice to have the option for a user to achieve that anyway in case an addon hasn't invested in a rich set of customizations like that.

Comment 5

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

Erik, want to take a look at the patch in comment 4?

Comment 6

[Erik Vold [:erikvold] (please needinfo? me)]

The patch looks alright, it would need tests and I'm not sure that 'userPosition' is best key, maybe just 'position' would be good enough.  What do you think Irakli?

Comment 7

[Irakli Gozalishvili [:irakli] [:gozala] [@gozala]]

(In reply to Erik Vold [:erikvold] [:ztatic] from comment #6)
> The patch looks alright, it would need tests and I'm not sure that
> 'userPosition' is best key, maybe just 'position' would be good enough. 
> What do you think Irakli?

I would personally prefer to be little more ambiguous about positioning, maybe by having
`group` instead + predefined set of group names that can be provided. That way item will just end
up in the right group but won't be disturb natural order of existing context menu items.


Also I'm curious if we do anything to address "could identify them anywhere in the list" poinint, which
I think is important detail.

Comment 8

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1399562