1376251 - Allow sidebar extensions access to native tab context menu

Status: RESOLVED DUPLICATE of bug 1280347

(WebExtensions :: General, enhancement, P5)

Description

[Geoffrey De Belie (Smile4ever)]

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:56.0) Gecko/20100101 Firefox/56.0
Build ID: 20170625030210

Steps to reproduce:

Sidebar extensions like Tab Center Redux which implement "Vertical Tabs" functionality currently can't use the tab (UI) context menu, forcing them to implement their own custom tab context menu, replicating standard Firefox functionality.

There are a few problems with this approach:
* Functionality might not work exactly the same as in the native tab context menu
* Items will be missing
** If Firefox adds new context menu items the addon won't have those immediately
** There is no WebExtensions API for "Send to device", so addons can't replicate that functionalty in the tab context menu of their own UI (which is HTML)
** WebExtensions that add their own context menus to the "tab" context won't be shown in the replicated tab context menu.

A way to show the tab context menu (some kind of API?) for HTML components in a sidebar extension is needed very badly.

https://bugzilla.mozilla.org/show_bug.cgi?id=1367160 is related.

Comment 1

[YUKI "Piro" Hiroshi]

I think the bug 1280347 aims to solve same problem. I also believe that we should not implement sidebar context menu by own.

Related issue on my "Tree Style Tab" addon: https://github.com/piroor/treestyletab/issues/1333

Comment 2

[YUKI "Piro" Hiroshi]

Another bug 1396031 seems including effective API proposal.

Comment 3

[Caitlin Neiman [:caitmuenster]]

Hi Geoffrey and Piro, this has been added to the agenda for the January 23, 2018 WebExtensions APIs triage meeting. Would you be able to join us? 

Here’s a quick overview of what to expect at the triage: 

* We normally spend 5 minutes per bug
* The more information in the bug, the better
* The goal of the triage is to give a general thumbs up or thumbs down on a proposal; we won't be going deep into implementation details

Relevant Links: 

* Wiki for the meeting: https://wiki.mozilla.org/WebExtensions/Triage#Next_Meeting
* Meeting agenda: https://docs.google.com/document/d/1Mc0h5OVd30WBjCORssdifZRXYQrk6WcTqX1cw6ADO9k/edit#
* Vision doc for WebExtensions: https://wiki.mozilla.org/WebExtensions/Vision

Comment 4

[YUKI "Piro" Hiroshi]

OK I'll join to the IRC channel while the meeting.

Comment 5

[Caitlin Neiman [:caitmuenster]]

This bug and bug 136031 have been approved.

Comment 6

[Kris Maglione [:kmag]]

My suggestion is that we provide sidebar contexts with an API to open the tab context menu for a given element by passing a tab ID and a context element. The extension would be responsible for listening to the contextmenu event and deciding when the context menu would be opened.

From an implementation perspective, we'd probably need the real context element to be mapped to the XUL tab, but we'd display it as if it belonged to the HTML version.

Comment 7

[Geoffrey De Belie (Smile4ever)]

(In reply to Kris Maglione [:kmag] (long backlog; ping on IRC if you're blocked) from comment #6)
> My suggestion is that we provide sidebar contexts with an API to open the
> tab context menu for a given element by passing a tab ID and a context
> element. The extension would be responsible for listening to the contextmenu
> event and deciding when the context menu would be opened.
> 
> From an implementation perspective, we'd probably need the real context
> element to be mapped to the XUL tab, but we'd display it as if it belonged
> to the HTML version.

Sounds good to me.

(In reply to Caitlin Neiman [:caitmuenster] from comment #5)
> This bug and bug 136031 have been approved.

You mean https://bugzilla.mozilla.org/show_bug.cgi?id=1396031

Comment 8

[Firefox Bug Husbandry Bot]

Bulk move of bugs per https://bugzilla.mozilla.org/show_bug.cgi?id=1483958

Comment 10

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

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.

Comment 11

[Geoffrey De Belie (Smile4ever)]

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.

Comment 12

[Rob Wu [:robwu]]

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.

Comment 13

[Geoffrey De Belie (Smile4ever)]

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