Closed Bug 1396031 Opened 3 years ago Closed 2 years ago

Create, parameters, contextParameters);


(WebExtensions :: General, enhancement, P3)



(firefox57 wontfix)

Tracking Status
firefox57 --- wontfix


(Reporter: ntim, Unassigned)



(Whiteboard: [design-decision-approved][contextMenus][ntim-backlog])

It would be nice to have a method that shows built-in context menus.

What I would suggest is the following API:, { location: "browser_action/page_action/sidebar_action/webcontent", x: ..., y: ..., }, contextParameters);

contextType corresponds to one of the following ContextTypes:

x and y are relative to the location.

contextParameters depends on the contextType chosen, for example, the tab context menu would take a WE tabId.

Use cases:
- Showing the tab context menu for sidebar tabs"tab", { location: "sidebar_action", x: ..., y: ... }, tabId);

You can reimplement the context menu from scratch, but that would have the following drawbacks: extensions can't integrate, the sidebar tabs extension will be out of date with firefox context menu changes, etc.

- Showing the bookmarks context menu for an advanced bookmarks manager

- UI tour for context menu items provided by an extension

An alternative approach has been suggested for the first use case: bug 1280347
Another alternative for the first use case would be having a browser.tabstrip namespace with 2 features:

- showing or hiding the tabstrip (bug 1332447)


- showing the tabstrip context menu

browser.tabstrip.showContextMenu(tabId, { location, x, y });
Whiteboard: [design-decision-needed]
This is very important for addon authors planning to migrate their addon including custom tab UI, from XUL to WebExtensions. Actually, my "Tree Style Tab" addon is already rebuilt on WebExtensions APIs mostly and only context menu is the largest one left as unmigrated feature...
(FYI, unsigned development build: )
Priority: -- → P3
Whiteboard: [design-decision-needed] → [design-decision-needed][contextMenus]
This bug as approved at the design decision triage meeting on January 23, 2018. 

Meeting notes can be found here:
Whiteboard: [design-decision-needed][contextMenus] → [design-decision-approved][contextMenus]
See Also: → 1376251
Whiteboard: [design-decision-approved][contextMenus] → [design-decision-approved][contextMenus][ntim-backlog]
Product: Toolkit → WebExtensions
We don't want extensions to open arbitrary menus without user interaction.

We do want to allow extensions to be able to develop custom tab/bookmark managers.

I'm going to mark this as WONTFIX because this specific API implementation suggestion will not be followed.
Instead, I'm going to implement the ability to specify a custom context when an extension menu is opened, in bug 1280347.
No longer blocks: 1466876
See Also: → 1280347
Closed: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.