Re: Automatic session resumption

Hi Anton, MarkFo, All,

On 15 Apr 2014, at 10:56, Anton Vayvod <avayvod@google.com> wrote:

> Dear community group members,
> 
> We would like to propose adding a way for the page to automatically reconnect to a session running on a second UA, without reprompting the user for screen selection.

Thanks for sharing your proposal with the group. I see how this would make the common use case of user visiting her favourite site to share content on the secondary screen more seamless process after the initial permission granting and session establishment.

I have couple of clarifying questions:

* The use case you have in mind is to allow the session to persist so that user’s consent is not required as long as the session is not explicitly closed e.g. by invoking close() on the session. Correct? 

* Should the user be able to disassociate the session through the UA somehow (think evil.example.com establishes a session the user would like to get rid of)?

To illustrate this a bit, let’s take an example of getUserMedia permissions on Chrome. When I click the padlock (https) or document (http) icon on the left side of the location bar, I’ll get a list of permissions for all feature regardless of whether the site uses them or not. For Media (aka gUM) the following drop down list is presented by default:

[ ] Always allow on this site
[ ] Always block on this site
[x] Use global default (ask|block)

[Note that the "Always allow on this site” option is only present if the content is served over https, a hint that the site is more trusted and the setting can be persisted. Other browser vendors may use different heuristics in figuring out whether the site is trusted or not.]

This dialog presented by the UA allows the user to opt-out from (or opt-in to) a feature at any time, which is good. Would there be something similar for the user to disassociate sessions?

Below further comments on the concrete proposal itself (assuming your proposal is extending the group’s recent thinking represented at [1]).

> IDL:
> 
> partial interface Presentation {
>   PresentationSession[] activeSessions();
>   EventHandler onsessionchange;
> }

s/Presentation/NavigatorPresentation/ I guess?

Do you think activeSessions() can return the list of PresentationSession objects in a reasonable time so that you don’t block the main thread? If there’s a possibility this takes longer than couple(?) of milliseconds, it would be better to either use a callback or return a Promise instead. Also making this asynchronous would allow some implementations to optionally prompt the user if they wish to.

> Code snippet:
> 
> var mySession = null, myUrl = “www.example.com/receiver”;
> 
> var found = presentation.activeSessions().some(function(session, index, array) {
>   if (session.url == myUrl) { mySession = session; return true; }
>   return false;
> });

> if (!found) {
>   // no active sessions, we'll either get a session from requestShow() or from
>   // the onsessionchange event listener.
>   mySession = null;
> };

The mySession variable was initialized to null, so this step is redundant IIUC? That would further simplify the example.

> presentation.onsessionchange = function(e)  {
>   var session = e.session;
>   if (session == mySession) {
>     // got an update for the session started/joined from this page

What would be the PresentationSessionState here? We may need to rework the states (see the PresentationSession interface at [1]) for a better fit. Feel free to propose a set of states that would work for your use case.

>   } else {
>     // |session| isn’t a session this page has started/joined,
>     // use it or not - up to the page
>   }
> }
> 
> Semantics:
> 
> If the browser has previously connected to any session or multiple sessions via |requestSession()| called from the same origin, e.g. 'http://example.com/sender', the |activeSessions()| array will contain the list of the session objects that can be used immediately from the current page.

[From the implementation point of view, this would be exposing something that the implementation keeps track of anyway to the web content.]

> |onsessionchange| event will be fired about the state change of any session started from the same origin as the current page.

Am I correct in assuming a screen can have 0-1 active session and N inactive sessions, where N is an implementation dependent limit, can be zero as well?

Assuming my above assertion is valid, then some pondering on the current design, and how this fits in with that:

A session is represented by a PresentationSession object. The onsessionchange event fires when the state of the session changes.

The onavailablechange fires when the screen state changes, but lives on the PresentationSession object currently — this seems a bit odd now.

Does it make sense to carve out something like “PresentationScreen” that represent the screen with its own states and handlers, to clearly decouple it from PresentationSessions?

WDYT?

We should aim for the simplest possible API that gets the stuff done, so please let me know if this sounds like an unneeded abstraction to you :-)

> Rationale:
> This permits a user to navigate a site (scoped by origin) while controlling the same instance of the presentation session, without having to interact with the browser to reconnect to the second screen each time.
> 
> Limitations:
> |activeSessions()| and |onsessionchange| will only work for a session that was started on the same browser from the same origin.  It will not return sessions started by other browsers.
> 
> We also want to add a way to disassociate an origin from a session, which would prevent the session to be visible to the pages with the origin.  This would be called e.g. when the user logged out from the site.

Thanks for your proposal.

All - I’d like to hear what others think about it before we spec it out more completely.

Thanks,

-Anssi

[1] https://www.w3.org/community/webscreens/wiki/API_Discussion#WebIDL

Received on Thursday, 17 April 2014 09:47:31 UTC