Closed Bug 1706675 Opened 4 years ago Closed 4 years ago

Add an API to call the "Share" command of Firefox itself (on Windows 10 and macOS)

Categories

(WebExtensions :: General, enhancement, P5)

Product:
WebExtensions
Component:
General
Type:
enhancement

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: yuki, Unassigned)

References

Details

Firefox's tab context menu has a command "Share" on Windows 10 and macOS. It depends on implementations for each platform, and currently it is not published for addons via WebExtensions API.
https://searchfox.org/mozilla-central/rev/d280cc26237b62096b89317e4ed6dea8b2bdf822/browser/base/content/tabbrowser.js#7240
Is there any chance that the feature to be implemented as an WebExtensions API?

This was originated from a feature request reported to an addon Tree Style Tab.
Add Share menu to Tab Context menus · Issue #2867 · piroor/treestyletab

This is pretty important, without this API or bug 1512851 being implemented, the Share functionality is completely inaccessible to Tree Style Tabs Proton users.

(In reply to kristoffer from comment #1)

This is pretty important, without this API or bug 1512851 being implemented, the Share functionality is completely inaccessible to Tree Style Tabs Proton users.

This is only the case if those users are hiding the existing tabstrip with userChrome.css, right?

Flags: needinfo?(kristoffer)

Yeah.(In reply to :Gijs (he/him) from comment #2)

(In reply to kristoffer from comment #1)

This is pretty important, without this API or bug 1512851 being implemented, the Share functionality is completely inaccessible to Tree Style Tabs Proton users.

This is only the case if those users are hiding the existing tabstrip with userChrome.css, right?

Yeah.

Flags: needinfo?(kristoffer)

Thinking about the abuse potential for exposing the Share functionality through the API is significant.

An alternative solution might be to use the existing overrideContext API, and simply add include the Share menu item when the new context is tab.
https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/menus/overrideContext

Rob, I think you designed that method, wdyt?

Flags: needinfo?(rob)

Having a command exposed (similar to _execute_browser_action) isn't likely to cause problems. It could then be attached to a menuitem the extension creates, or via keyboard. We would then control the calling of share, and using the command requires user input. There is also an interstitial dialog the user has to use to complete the share.

The share menu code itself is tied to specific element IDs in order to build the submenu, I'm not clear how that translates to the overrideContext stuff but rob would know.

The menus.overrideContext method (that TST already uses after it was implemented in bug 1280347) can currently not be used to insert an arbitrary menu item in an unrelated menu. It offers the ability to add custom menu items (bug 1280347), and to optionally hide the default menu items. The "default" menu items are the usual menu items that would be shown in the page context, not "tab" context menu items when the extension uses browser.menus.overrideContext({ context: "tab", tabId }).

There is another related feature request, asking for the "Send Tab to device" menu (bug 1469764), which hasn't been implemented. Piro (the TST author) has simulated the feature in a different way when the feature request for this to be a built-in extension API was rejected (bug 1417183).

There is no precedent yet for including built-in menu items in the menu. I intentionally stayed away from that at the design of the menus.overrideContext API, because it means that we have to introduce support for every menu on a case-by-case basis (since the command handlers for each menu item need to be checked/refactored/tested to make sure that they also work as intended with an extension-provided tab).

(In reply to Shane Caraveo (:mixedpuppy) from comment #5)

Having a command exposed (similar to _execute_browser_action) isn't likely to cause problems. It could then be attached to a menuitem the extension creates, or via keyboard.

"command" is tied to the commands API (extension shortcuts). This might make sense when we only want to support clicks on menu items. In the two feature requests related to this, the menu items are not single menu items, but a parent to a submenu. If we were to provide placeholders, then I think that we should introduce a separate property that throws/rejects the API call if the requested placeholder is not supported, because that allows extensions to detect the availability of the feature and provide alternatives if needed. If we document that the built-in placeholder may be unavailable (e.g. not available on platform or removed in a feature release), then I suppose that support for this feature wouldn't be a maintenance burden.

browser.menus.create({
  type: ["placeholder"],
  placeholderId: "tab-share,
}, () => {
  // TODO: check if browser.runtime.lastError is set.
});

(note: using runtime.lastError above because of bug 1527979)

Let's discuss this at the next triage meeting, to see whether we would accept such a feature. I would be willing to review patches.

Flags: needinfo?(rob)
See Also: → 1469764

"command" is tied to the commands API (extension shortcuts). This might make sense when we only want to support clicks on menu items. In the two feature requests related to this, the menu items are not single menu items, but a parent to a submenu.

I don't understand this. I see both Share and Send to Device as menu items that open a modal dialog.

(In reply to Tomislav Jovanovic :zombie from comment #7)

"command" is tied to the commands API (extension shortcuts). This might make sense when we only want to support clicks on menu items. In the two feature requests related to this, the menu items are not single menu items, but a parent to a submenu.

I don't understand this. I see both Share and Send to Device as menu items that open a modal dialog.

I see a menu item that hosts a submenu, e.g. for the "Send to Device" option:

(In reply to Rob Wu [:robwu] from comment #8)

(In reply to Tomislav Jovanovic :zombie from comment #7)

"command" is tied to the commands API (extension shortcuts). This might make sense when we only want to support clicks on menu items. In the two feature requests related to this, the menu items are not single menu items, but a parent to a submenu.

I don't understand this. I see both Share and Send to Device as menu items that open a modal dialog.

I don't know about Send To Device (I think that's always a submenu?) but Share is a submenu on macOS, but a button that opens an OS dialog on Windows. It is not supported on Linux.

In any case we should treat it as a placeholder by design, as that offers more flexibility to us as Firefox engineers to change the implementation if needed.

We have decided to accept this feature request. Comment 4 sketches an example of an API. The semantics haven't completely been spelled out, but it should be obvious. If not, feel free to ask. The placeholder menu items should only be shown in menus created with overrideContext.

Piro, are you interested in contributing patches?

Severity: -- → N/A
Flags: needinfo?(yuki)
Priority: -- → P5

Can you please focus on this, or preferably bug 1512851, as of Firefox 89 I'm forced to open Chrome all the time to just airdrop stuff! It's so damn backwards.

Adding the Share menu to the File Menu is btw a way simpler solution for all parties than creating an API and implementing it in TST. I don't imagine copying the Share menu code from the old menu and modifying it to fit into the File Menu can be that hard.

It is also a way better solution, the File Menu is where it is common for all applications to share the content, including all other browser. Send as Email is already there, and spreading different sharing functionality all over the browser is horrible UX. This shouldn't be that hard.

Yuki, are you interested in implementing this?

See Also: → 1512851

After discussing this with the extension team and Firefox frontend people, we've decided to not proceed with this extension-specific API.

Rather, bug 1512851 should be resolved, as that removes the need for this API, with the added benefit that all users (even those without extensions) can use the menu item.

To anyone interested in this feature: I have posted detailed instructions to implement this feature in Firefox at https://bugzilla.mozilla.org/show_bug.cgi?id=1512851#c8

Status: NEW → RESOLVED
Closed: 4 years ago
Flags: needinfo?(yuki)
Resolution: --- → WONTFIX

Not sure if this is the right place for this, but I was linked here through this bug (https://bugzilla.mozilla.org/show_bug.cgi?id=1690569). When using TST under Linux and Firefox 89, with the meatball menu removed, there's no way to send a tab from desktop to mobile, because TST can only send to devices with TST installed, which doesn't include mobile.

This is a significant regression as I rely on this feature very frequently, and I can't be alone here. Should a new bug be filed for this?

I apologize to my silence. I couldn't take a time to concentrate to track this topic.

I agree that a "Share" command in the "File" menu is reasonable. I just saw the "Share" command on Windows 10, it always shows a dialog provided by Windows itself, thus I thought that exposing the command to WebExtensions API is easy. I didn't know the "Share" menu item has its sub menu on macOS. I saw similar discussion about the "Send Tab to Device" command, and I couldn't find out any good idea to ask Mozilla developers to expose the feature including sub menu to extensions safely.

By the way, something API like browser.tabs.requestShare(tabId) looks still helpful for extension authors who want to implement a feature like "opening a tab automatically for a specific web service and share it immediately". It will require to implement an extra dialog to choose the share target on macOS. Is there no chance to add such an API?

You need to log in before you can comment on or make changes to this bug.