1308059 - Implement sessions.getDevices WebExtensions API

Status: NEW

(WebExtensions :: General, enhancement, P5)

Description

[Bob Silverberg [:bsilverberg]]

Implement browser.sessions.getDevices method, which is documented at https://developer.chrome.com/extensions/sessions#method-getDevices.

Comment 1

[Bob Silverberg [:bsilverberg]]

Based on the lack of response/interest to the intent to implement email for this feature I am marking it as a P5 and unassigning myself from it.

For future reference, the content of the intent to implement email regarding this was:

-----------------------

We have been looking into implementing the getDevices method of the sessions API and a question has come up about whether we should implement it for Firefox or not. Syncing is a bit different between Chrome and Firefox: in Firefox we have the concept of synced tabs, but not windows.

The Chrome sessions.getDevices API returns an array of Device objects, each of which contains an array of Session objects, each of which contains an open Window object, each of which in turn contains an array of Tab objects. This is documented [1].

The issue here is that the current architecture of Firefox Sync does not have the concept of a synced window, only synced tabs. Therefore we are not able to return an array of Sessions each of which contains an open Window object, but we are able to return an array of Session objects, each of which contains an open Tab object. This is strictly legal, as a Session object can contain either a Window or a Tab object, but it does not conform to the description or behaviour of the Chrome API.

An option would be to wrap all of the synced tabs we find in a single fake window object, which would allow us to return a Session that contains a Window rather than a Tab, but I'm not sure if that is a good idea.

If you have any feedback or suggestions about this issue please reply to this thread.

Thanks,
Bob
 
[1] https://developer.chrome.com/extensions/sessions#method-getDevices

-----------------------

Comment 2

[Richard Newman [:rnewman]]

(In reply to Bob Silverberg [:bsilverberg] from comment #1)
> Based on the lack of response/interest to the intent to implement email…

Where was this email sent, Bob? I don't remember seeing it on sync-dev or firefox-dev.

Comment 3

[Bob Silverberg [:bsilverberg]]

(In reply to Richard Newman [:rnewman] from comment #2)
> (In reply to Bob Silverberg [:bsilverberg] from comment #1)
> > Based on the lack of response/interest to the intent to implement email…
> 
> Where was this email sent, Bob? I don't remember seeing it on sync-dev or
> firefox-dev.

That's because it was sent to dev-addons, which is where we generally send intent to implement emails for APIs. If there is renewed interest in this feature, or something like it, we can discuss it in this bug.

Comment 4

[Richard Newman [:rnewman]]

For posterity, the direct link:

https://mail.mozilla.org/pipermail/dev-addons/2016-October/001980.html


I think there's some amount of renewed interest; we discussed Bug 1385965 recently, which I expect will shortly be duped here.

Comment 6

[Sören Hentzschel]

bug 1385965 got a "design-decision-approved" and was marked as duplicate of this bug so the whiteboard label should be added to this ticket.

Comment 7

[Tim Nguyen :ntim]

(In reply to Sören Hentzschel from comment #6)
> bug 1385965 got a "design-decision-approved" and was marked as duplicate of
> this bug so the whiteboard label should be added to this ticket.

The API in this bug already exists on Chrome, so that's already an implicit approval.

Comment 8

[Mike Conca [:mconca]]

As of today, there are only 17 extensions on the Chrome web store that use this API, so we will not be implementing this for compatibility reasons (particularly given the platform differences mentioned in Comment 1).  The status will remain P5 and patches are always welcomed.

Comment 9

[ariasuni]

(In reply to Mike Conca [:mconca] from comment #8)

As of today, there are only 17 extensions on the Chrome web store that use
this API, so we will not be implementing this for compatibility reasons
(particularly given the platform differences mentioned in Comment 1).

I’m pretty sure that not a lot of Chrome extensions are using this API, but how did you find this information? It could good to have an up-to-date count.

Comment 10

[BugBot [:suhaib / :marco]]

The severity field for this bug is relatively low, S3. However, the bug has 43 votes.
:robwu, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 11

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Comment 12

[adapasainath]

Adding a concrete current user/developer use case for renewed interest.

I wanted to build a small Firefox extension that exposes "Tabs from other devices" as a persistent searchable launchpad page. Desired workflow:

• List native synced tabs grouped by source device.
• Click a remote tab to open its URL in a new background tab, e.g. browser.tabs.create({ url, active: false }).
• Keep the launchpad page open so the user can open many remote tabs one by one without repeatedly navigating through Firefox View, the sidebar, or the account menu.
• Support search/filtering and possibly bulk-open actions.

Firefox already exposes this inventory in Firefox View, Synced Tabs, and the account panel, but WebExtensions do not appear to have read access to the native synced remote-tab data. Extension-managed storage.sync is not an acceptable substitute for this workflow because it cannot see iOS Firefox tabs, does not use the user's existing synced-tab inventory, and has sync/quota/platform limitations.

I don't think Chrome-compatible window/session semantics are necessary for this use case. A Firefox-shaped read-only API returning devices with flat tab metadata would be enough:

• device id/name/type
• tab title
• tab URL
• favicon URL when available
• last modified/accessed timestamp when available

Privacy-wise, an explicit permission warning seems appropriate because this exposes browsing activity. Read-only access alone would unlock a useful class of launchpad/tab-management extensions; remote close/send could be separate permissions or omitted initially.

This is a real user-facing product gap: the built-in UI works for occasional use, but not for a persistent command-center workflow for opening many remote tabs while staying on the list.