1417183 - Provide a web extensions API-based way to send pages between devices

Status: RESOLVED WONTFIX

(Firefox :: Sync, enhancement, P5)

Description

[Edouard Oger [:eoger]]

I have made a proposal:
https://docs.google.com/document/d/1dCp24WQSIFcE-GcjNbjSyGwzBilRcljllN_dAIhrzYM/edit

There's also a few privacy/security considerations we could have:
- what if a rogue extension uses this API to spread a compromised page?
- is that okay to expose device info (names, os..) to extensions?

Comment 1

[Richard Newman [:rnewman]]

Making a note for myself to read and comment on this.

Comment 2

[Andy McKay]

Possibly related: https://developer.chrome.com/extensions/identity#method-getAccounts

Comment 3

[Richard Newman [:rnewman]]

Also related: Bug 1308059. `getDevices` seems relevant to what you're trying to do.

Comment 4

[Caitlin Neiman [:caitmuenster]]

Hi Edouard, this has been added to the agenda for the WebExtensions APIs triage on April 10, 2018. 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/1cFcqNOLwp77aosh5QUeNKgW8FQONAzOBlqjbcbxdIXw/edit#
* Vision doc for WebExtensions: https://wiki.mozilla.org/WebExtensions/Vision

Comment 5

[Croydon]

I would like to have this API in place in order to provide a "Send to device" option in Vertical Tabs Reloaded.

Comment 6

[Caitlin Neiman [:caitmuenster]]

Hi Richard, we talked about this in the WebExtensions APIs design-decision meeting and we wanted to ask for your input as to whether or not this proposal should be approved. 

Also flagging :aswan to put this on his radar.

Comment 7

[Andrew Swan [:aswan]]

In short, the result of the triage meeting was that we agreed this seems like a useful thing to expose to extensions, but that all the expertise on what should be exposed and how it should be exposed lies with the sync team.

I think the biggest design question here would be what to do about cross-browser compatibility.  Google Chrome has extension APIs that touch some aspect of sync in their identity, gcm, and sessions APIs (and maybe others too).  Off the top of my head, I don't think their existing APIs are something worth duplicating, perhaps creating a new API namespace (e.g., browser.sync) would make more sense.

In any case, this seems like a useful thing to have, ideally it would be driven by the sync team.

Comment 8

[David Durst [:ddurst]]

Redirecting to Sync team, as that would be the pre-req for what we could do here.

Comment 9

[Richard Newman [:rnewman]]

(In reply to Caitlin Neiman [:caitmuenster] from comment #6)
> Hi Richard, we talked about this in the WebExtensions APIs design-decision
> meeting and we wanted to ask for your input as to whether or not this
> proposal should be approved. 

I left some lower-level feedback on Ed's doc back in November.

My current opinions on this:

I have doubts about exposing the details of devices through this kind of API (modulo however that would happen as part of Bug 1385965).

We have already grown optional fields, some of them quietly misleading, on the clients record.

There are two sources of truth for clients. From one perspective we're growing a third -- push registration -- and some of the data in e.g., the clients record will be increasingly misleading as we rewrite how push happens (e.g., lastSync — is that the last time that device connected to the push service, or the last time it uploaded a client record?).

If we add a capability like sending a tab without picking a device ("park this tab in the cloud"), will we add some kind of bogus placeholder device?

Etc. etc.

The simplest thing I can see working is to delegate device choosing, rate limiting, etc. to the browser. An extension would invoke the API, and the browser chrome would activate to choose a device from an updated list.

(This will also presumably improve user education around send tab, and also deliver a more polished device picking experience than most extensions would build.)


Furthermore, we've wanted to include more page state in sent tabs for 6 or 7 years — maybe cookies, certainly some form fields, scroll position. A proposal that only works with URLs (not even titles!) will give extension-sent tabs a worse experience.

The API exposed to extensions would then be:

- Please send the current page/this document to another device. That'll take with it as much state as we can extract from the document.
- Please send this URL, with this title, to another device.
- Is send tab a capability that this browser has?

A promise would be returned from each of the send methods, filled or rejected when a device is chosen and the tab is queued. Potentially that promise could resolve to a structure that allows the extension to send again to the same device as last time.

Ed, what do you think?

Comment 10

[Edouard Oger [:eoger]]

Sorry for the delay. I generally agree with that comment.

> - Please send this URL, with this title, to another device.
This would require UI/front-end work to make it clear to the user that they are sending a specific URL instead of the current page.

> A promise would be returned from each of the send methods, filled or rejected when a device is chosen and the tab is queued. Potentially that promise could resolve to a structure that allows the extension to send again to the same device as last time.

That would require to do a bit of state tracking in the UI (what happens if you change windows, dismiss the dialog and so on), but could be doable. We could also not return any promise, just open the popup.

I don't care too much about that API being implemented (I'd rather have bug 1376251 - see my motivation for opening this bug in comment 0's google doc), but if extension makers express interest in it I'm not opposed to it.

Comment 11

[Richard Newman [:rnewman]]

> > - Please send this URL, with this title, to another device.
> This would require UI/front-end work to make it clear to the user that they
> are sending a specific URL instead of the current page.

FWIW, this capability would be needed to support right-click "Send this tab" in the tab tray, or for an extension to do things like link-rewrite-and-send in content.

I don't think this requires UI work in the way you imply. Right now you can right-click a tab, choose Send Tab To Device, and pick a device; the tab picking/link clicking experience makes it clear what's being sent, and the device picker makes it clear which device will receive.

I'm just suggesting that we draw the line between extension and Firefox after step 2, not after step 3.

Comment 12

[ariasuni]

Any news on this?

Comment 14

[ariasuni]

So it’s been 2 years since the last real discussion here (sadly I can’t see the original proposition), so here’s my proposition.

Compatibility

According to this comment, Firefox and Chrome works differently with regards to tabs synchronization and the API is not used much by Chrome extensions, and implementing this for compatibility was rejected (thus the P5 priority on this other bug report).

So I suppose it’s fine to introduce a new API better suited to Firefox’s needs.

API

My idea is to introduce an API similar to contextualIdentities.

• Introduce a new permission, syncDevices («Get the list of your synchronized devices and send pages to them»)
• syncDevices.Device: { id, icon, iconUrl, name }.
  • icon should be one of: desktop, phone, tablet, tv, vr.
• syncDevices.query(): return a list of Devices
• syncDevices.onCreated/Removed/Updated: to listen to changes in devices.
• syncDevices.send(tabId, deviceId): send tab with tabId to device with deviceId (can only be called from inside the handler for a user action). To send to all devices, either deviceId could be omitted, or the dev could be required to use a special syncDevices.DEVICE_ID_ALL.
• Could be extended later to include a way to get synchronized tabs (e.g. with a limited syncDevices.Tab type with the bare minimum fields, a method to query sync tabs by device, listeners for changes and a method to open a tab based on its id and deviceId).

Security

The API can only send already opened tabs, as it is the case in Firefox UI. So either the extension can’t create tabs, or the user already trusts it to not open malicious websites. In both cases, sending a tab to a device needs a user interaction (in my proposition), but I’m not sure it’s enough (I suppose it would be nice to forbid several calls to syncDevices.send() in response to the same user action).

Since my proposition is to add a new API/permission, this feature will only be available for extensions that specifically request it. The few extensions using this API could receive additional scrutiny/review by AMO reviewers.

Comment 15

[Mark Hammond (PTO; back Oct-3) [:markh] [:mhammond]]

cc Ana - this is an old proposal from Ed to expose send tab to extensions, with the idea being that we might encourage some novel/interesting applications for the feature.

Comment 16

[ariasuni]

Any news on this, or feedback on my proposal?

Comment 17

[janet [:janet]]

marking as wontfix - can revist if there's a clear product ask for this feature.

Comment 18

[Félix Saparelli [:passcod]]

What qualifies as a clear product ask? Is this a Mozilla-internal thing? There are several existing extensions that are waiting on this functionality.

Comment 19

[YUKI "Piro" Hiroshi]

I'm one of extension authors waiting for this API. My product Tree Style Tab provides a vertical tab bar for very large number of tabs, and it still cannot provide the "send tab to device" command due to this restriction. It is painful for me to find to-be-sent tabs from Firefox's native tab UI when there are large number of pinned and unpinned tabs.

Comment 20

[YUKI "Piro" Hiroshi]

Attachment: Screenshot describing needfulness of custom "send tab to device" command based on this API

Please see this screenshot for more explanation.

Comment 21

[Mark Hammond (PTO; back Oct-3) [:markh] [:mhammond]]

Can't you just select the tab first? That's one extra click. Note also that it's not as simple as "just expose it" - we need to do it in a way that's safe (both from a privacy perspective and functionality/performances/abuse perspective) from addons without good intentions, and we can't prioritize that work at the moment.

Comment 22

[Félix Saparelli [:passcod]]

It's always available as a right click from the tab. Fine. That doesn't help for extensions that entirely replace the native tab bar. Additionally, selecting the tab to get access to the addressbar menu means the page gets loaded, while right-clicking (or having an API) doesn't. In any case, the reaction here is on the bug getting closed as wontfix rather than left open; completely understandable that it's not prioritised (the age and history of the bug make that obvious).

Comment 23

[YUKI "Piro" Hiroshi]

(In reply to Mark Hammond [:markh] [:mhammond] from comment #21)

Can't you just select the tab first?

Yes, the workaround is effective for the case when I hope to send a foreground tab, and I ordinarily use that way for now.
It still hard for me to send background tabs. If they are pended (unloaded), the operation always load those tabs before sent.

I think it is enough safe and reasonable that requesting a new permission to list sync devices with a warning message, but I have no more objection if you and Firefox developers say it is not safe enough.