Clarifies when and how presentations are terminated

[mfoltzgoogle]

This addresses #18 (Define reconnection for cross-page navigation on presenting user agent) by specifically terminating the presentation when navigation is attempted (other than by fragment identifier). It also spells out the other circumstances in which a presentation is to be terminated. This list may not be comprehensive; please point out anything missing.

Reading this, it looks like there are three distinct algorithms:

1. What happens when a controller terminates the presentation
2. What happens to the presentation
3. How connected controllers should respond to the terminated presentation

Perhaps it would be clearer to split 2 and 3 into separate sections. Thoughts?

[tidoust]

I think that the "unload a document in response to a request to navigate" circumstance should be generalized to "unload a document". This will also catch other circumstances that unload the document, e.g. reloading the page.

Also, I think that you can drop the window.close() circumstance and the bits that call out navigating the context and navigating among fragment identifiers. Procedures defined in HTML5 ensure that calling window.close() or navigating the context will unload the document, except when the navigation boils down to scrolling to a fragment identifier, so these cases don't have to be called out in the Presentation API:
https://www.w3.org/TR/html5/browsers.html#dom-window-close
https://www.w3.org/TR/html5/browsers.html#navigate
https://www.w3.org/TR/html5/browsers.html#scroll-to-fragid

The procedure could still mention them as examples:

<li>The <a>receiving user agent</a> is to <a>unload a document</a> corresponding to the
<a>receiving browsing context</a>, e.g. in response to a call to <code>window.close()</code>
in the <a>top-level browsing context</a> or to a request to <a>navigate</a> that context to a
new resource.</li>

... perhaps completed with something like:

<p class="note">Navigating to a fragment identifier within the same document does
not cause the document to <a data-lt="unload a document">unload</a>.</p>

In the case where the receiving user agent closes the presentation at user request, couldn't there valid cases where the user agent may want to terminated the presentation but not unload the document? For instance, the receiving user agent could offer an option to drop all controllers from the current presentation, effectively turning the presentation back to a regular page (only useful provided some user interaction is possible on the receiving end, of course). Or do we want to prevent that possibility on purpose?

In other words, I would leave unloading the document up to the receiving user agent in that case, and replace the paragraph that starts with "In any of these cases", by:

<p>In addition, when a <a>receiving user agent</a> receives a signal from a <a>controlling
user agent</a> via the algorithm to <a data-lt="terminate-algorithm-controlling">terminate a
presentation in a controlling browsing context</a> that the presentation should be terminated,
it MUST <a>unload a document</a> corresponding to the <a>receiving browsing context</a>.
</p>

[anssiko]

I submitted a PR #264 (using w3c/issue-18-receiving-navigation as the base) in an attempt to split this into 3 sections. Also did some other editorial changes, and added definitions for signals.

I did not yet bake in @tidoust suggestions to keep this purely editorial.

@mfoltzgoogle Feel free to merge if this looks digestible.

[mfoltzgoogle]

Thanks @tidoust for the feedback!

The procedure could still mention them as examples:

I went ahead and updated this text as suggested. It's an improvement as I don't want to try to replace or amend the HTML5 spec around unloading. :)

In the case where the receiving user agent closes the presentation at user request, couldn't there valid cases where the user agent may want to terminated the presentation but not unload the document?

In my mind "terminate" means that effectively the presentation no longer exists therefore and cannot accept new connections. Without the unloading requirement, the controller won't have any way of ensuring the presentation stops doing what it's doing (playing a video, etc.).

I could imagine a button in the browser (or on a remote control for the display) that says "disconnect", versus "terminate." I think if this use case is important to support, we would write a separate algorithm to "disconnect a presentation" which would close all open connections, and fire a PresentationConnectionCloseEvent in the controlling context(s) instead of a terminate event.

Do you mind filing a separate issue with tag "enhancement" with this idea?

[mfoltzgoogle]

Updated PR addresses the feedback above. It also

• Replaces "termination signal" with "termination request" and "termination confirmation"
• Adds explicit steps for terminating a presentation in a receiving browsing context

[anssiko]

LGTM with comments.

[mfoltzgoogle]

Going ahead and merging. @tidoust, if you have further thoughts on adding a "disconnect presentation" enhancement, let's work on that separately.