This got marked as a duplicate of bug 1280347, but it sounds from my understanding that 1280347 didn't end up covering everything that this bug wanted to have covered.

If I understand correctly, 1280347 allowed extensions to include the context menu additions that other installed extensions have created.

This bug, as originally filed wanted to also provide access to the browser's native context menu entries so that things like Send Tab To Device can be done without having to wait for bug 1417183 to add a webextension api that webextensions can use to duplicate that functionality.

Is there any chance we could reopen this bug to handle that original request?

Edit: My reason for bumping this is that I'm a heavy user of Tree Style Tabs, and I'd love to be able to hide the native tab strip (preferably with bug 1332447's eventual API, but userChrome.css would be just as acceptable in the immediate future) to cut down on visual clutter and redundancy with my better-organized sidebar, but it's the only place to easily get to the Send Tab to Device option for arbitrary tabs. If at least parts of the native context menu (specifically Send Tab To Device and its sub-menu listing the devices) could be pulled in to Tree Style Tab's customized context menu, I could freely hide the now-fully-redundant(-for-me) tab strip.

Yes, accessing "native" features was part of my original request.

I'm happy that bug 1280347 got solved since it brought tab extensions like Tab Center Reborn on almost feature parity with the native tab bar implementation.

But we could do better, asking for certain tab menu context items to be included in our custom sidebar tab implementation. The quote below mentions that all tab specific items aren't included and that's at the moment what this bug is trying to solve (item by item, where it makes sense).

It doesn't seem a problem to use magic strings or constants like SEND_TO_TAB because if the name changes, probably the extension needs to change as well.

Quote from bug 1280347 (RobWu):

I'm not literally going to support HTML attributes, but I do intend on adding a new API that can be called from the "contextmenu" DOM event to set a custom context (bookmark or tab, initially).

The main goal of this new API is to allow extensions to hide all default menu items in favor of their own (bug 1367160), and to support automatic inclusion of tab/bookmark-specific menu items from other extensions.

Including Firefox's default menu items is out of scope, because the default menu labels don't always make sense. For example, the "Close Tabs to the Right" menu item makes no sense in a vertical tabs-type extension.
If there are menu items that cannot be replicated with the extension APIs, then we can decide on a case-by-case basis for how this should be supported.

Thank you for reconsidering and reassigning to someone else if needed.

The menus.overrideContext API was designed to offer the flexibility of fully customized context menus, with minimal coupling between Firefox's UI and (optional) extension functionality. This allows both Firefox and extensions to evolve independently. Ideally extensions should be able to replicate the functionality with extension APIs.

The "Send Tab to Device" menu item offers the following functionality:

• Shows whether the user is signed in to sync, and if so, the list of devices that can receive a tab. (bug 1308059)
• Shows the "Sign in to Sync" menu item, that opens the "Sync" tab of the browser's preferences UI. (no bug)
• Send tab to one of the chosen devices upon selecting one of the devices. (bug 1417183)
• (also a menu item that supposedly opens documentation on the feature, but that link is currently not really helpful -
  bug 1578192; in any case this menu item can already be replicated with the tabs.create API)

Bug 1308059 and bug 1417183 are probably not going to be resolved anytime soon.

The functionality of sending tabs to a device does not strictly require extensions to know the list of tabs. If we offer the ability to insert a menu item that has the default "Send Tab to Device" functionality, then the only capability that extensions get is the ability to allow users to send a tab to a device. This functionality would be covered by the existing "tabs" and "menus" permissions.

I think that the best way to offer this functionality is with a new option in the browser.overrideContext method. The main things needed are 1) ability to express interest in the menu item and 2) ability to specify the desired location of the menu item.

If you are interested in such functionality, open a new bug (and link to this comment for context). I am willing to review API design proposal and patches.

Done, see https://bugzilla.mozilla.org/show_bug.cgi?id=1578655