Bob Silverberg [:bsilverberg] Reporter
	Description • 8 years ago

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

	Bob Silverberg [:bsilverberg] Reporter
	Comment 1 • 8 years ago

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

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

	Richard Newman [:rnewman]
	Comment 2 • 7 years ago

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

	Bob Silverberg [:bsilverberg] Reporter
	Comment 3 • 7 years ago

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

	Richard Newman [:rnewman]
	Comment 4 • 7 years ago

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.

	Sören Hentzschel
	Comment 6 • 6 years ago

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.

	Tim Nguyen :ntim
	Comment 7 • 6 years ago

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

	Mike Conca [:mconca]
	Comment 8 • 6 years ago

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.