Open Bug 1308059 Opened 6 years ago Updated 2 years ago

Implement sessions.getDevices WebExtensions API

Categories

(WebExtensions :: General, defect, P5)

defect

Tracking

(Not tracked)

People

(Reporter: bsilverberg, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [sessions]triaged)

Implement browser.sessions.getDevices method, which is documented at https://developer.chrome.com/extensions/sessions#method-getDevices.
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

-----------------------
Assignee: bob.silverberg → nobody
Status: ASSIGNED → NEW
Priority: P2 → P5
No longer blocks: 1300399
Blocks: 1226546
(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.
(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.
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.
Duplicate of this bug: 1385965
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.
(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.
No longer blocks: 1226546
Product: Toolkit → WebExtensions
Blocks: 1476144
No longer blocks: Session_managers
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.

(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.

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