Refine how to do session teardown/disconnect/closing

[drott]

There are rough edges when it comes to closing the session, resuming it. We need to gain experience from implementations what happens, when the session is disconnected, user-closed, remote-end closed etc.

This section is one aspect of this, but probably the example section needs to shed more light on how expected and unexpected disconnects are handled.

[drott]

https://lists.w3.org/Archives/Public/public-secondscreen/2015Jan/0012.html (End of the mail "semantics of close"

[markafoltz]

Copied from #33:

Presumably the user agent will provide the ability for the browser with the initiating page to close the presented document (local or remote). However we may want the user agent to close it on the user's behalf when:

1. There are no controlling sessions connected for some period of time (e.g., idle timeout)
2. The presentation is being rendered locally (1-UA) and the media stream has has been terminated permanently.
3. The presentation is being rendered locally and the user wishes to exit the user-agent.
4. The presentation wishes to terminate itself.

Some of these scenarios can be implemented by the app developer; if so the behavior of e.g. window.close() should be defined in the presentation context.

[schien]

I'd like to put my two cents before the F2F meeting.

Currently PresentationSessionState only support two states: connected and disconnected, which is not enough for both requesting page and presenting page to distinguish between terminating the presentation or presentation display being disconnected accidentally.

This can be solved by introducing additional state terminated. While session.close() (or rename to session.terminate()) being invoked, session.state will enter terminated state. Application can reclaim the resources and terminate itself, e.g. closing the window.

[markafoltz]

Thanks, that seems reasonable. Other options that I would put forth for consideration:

1. Adding a disconnectReason property to the statechange event that lets the page know why the PresentationSession was disconnected.
2. Adding an error event (and handler) to PresentationSession. If the session was terminated accidentally, this would fire. This is similar to RTCDataChannel [1], although the semantics of RTCDataChannel.onerror are not clear from that spec.

[1] http://www.w3.org/TR/webrtc/#rtcdatachannel

[matt-hammond-001]

Some underlying protocols may not support terminating/closing the 2nd screen content. In DIAL, the ability to "stop" an application is optional [1]. Similarly HbbTV (that builds ontop of DIAL) does not mandate this functionality.

The behaviour is also not always needed. For example: a user browses a catalogue of video on demand on a mobile device and chooses a show. They "cast" it to the TV to watch it there and will continue to watch it, even if they close the webpage on the mobile device or take some other action within that page that moves them onto looking at other content on the primary screen.

I would therefore propose that session.close() or session.terminate() can fail silently if the underlying protocol does not support this action. Alternatively the requirement to support a close/terminate capability could be indicated when checking availability or trying to start a session.

[1] DIAL 1.7.1 spec section 4 or 6.4 at http://www.dial-multiscreen.org/dial-protocol-specification

[tidoust]

PROPOSED RESOLUTION: for #35, add a "terminated" state to the list of connection state and clarify in the spec what happens on the presenting side when "close" is called (in one-to-one scenario, killing the application)

See relevant discussion during first day of Berlin F2F:
http://www.w3.org/2015/05/19-webscreens-minutes.html#item10

[sicking]

I like the idea of "terminated". Though it doesn't really answer the question of when the page on the TV is closed, does it?

I was first thinking that we could make the statechange event when we transition to "terminated" be cancelable, and make the default behavior be to close the page on the TV. I.e. we'd close the page by default, but the page can override by calling .preventDefault().

However that's somewhat awkward for a couple of reasons.

First of all it's only when the last PresentationSession object is terminated that we would want to close the page.

Second, it's a bit weird to cancel a statechange event since no matter what, the state does change. It's the closing of the page as a result of it that may or may not happen.

So maybe we should fire a "lastsessionterminated" (please come up with a better name) event on the navigator.presentation object when the last session is terminated. The default action of this event would be to kill the page. If the event is cancelled the page stays open.

Either way, I think the page can at any time call window.close() to close the application on the TV.

[schien]

The timing of closing window varies from application to application, e.g. multi-player game might wait for more incoming session and remote video play might want to close the window immediately. The question here would be: should we default close the window or not?

If window is not closed by default, adding "terminated" state should be enough because applications can monitor the session state by themselves.

If window is closed by default, we'll have to use the preventDefault() technique mentioned by @sicking in comment 3.