Re: [spec-reviews] Write up the Secure Stop issue for ddorwin (#73)

## Architectural view on run-after-app-close behavior.

A question was posed to the TAG: some potentially synchronous operation are requested to be run "after application close", with clarifying statements about the durability, reliability, or timeframes that these operations are required to run within. 

The context for this question is described in [issue #85](https://github.com/w3c/encrypted-media/issues/85), a debate about the inclusion of a feature in EME that would specify shutdown behavior. In this response, we only seek to clarify  the architectural question of requiring steps to run after application close; we make no value judgement of the feature in question or implementation strategies vendors might choose.

The most basic app-close (e.g., "shutdown") activity that impacts the web platform is navigation, which causes documents to be created and destroyed. From the point of view of the document, its life-cycle starts after retrieving and parsing the resource's URL and ends when it is moved into the navigation history (when it is then "destroyed", but the exact timing of this is UA dependent). The management of documents and their life-cycles are provided by the browsing context. When a user closes a top-level browsing context (e.g., a browser tab) this results in the demise of both the current document (which should run unloading steps, as noted in the HTML specification, but might not) as well as its session history. Unlike documents, browsing contexts do not explicitly have life-cycle hooks.

When documents are destroyed, e.g. by navigation, JS objects are destructed. But this isn't the only time that can happen: in JavaScript the precise semantics of object destruction/collection are not made available to author code. Care is given in specs to make sure GC isn't made observable. Internal behavior may hold onto objects, but this is sort of "weird" from the layered-platform perspective. If something isn't in the retained object graph in JS, it's odd for it to "live" longer than references or the JS context.

Implementations may differ on the exact behavior of shutting down a browsing context, but most will start by unloading the document, following the steps described in the HTML specification that lead to the `beforeunload` event (so that the user can cancel the operation). Beyond that, the browsing context is essentially committed to shutting down and various optimizations are employed so that a minimal amount of subsequent code is run (for reasons of performance and battery life). Closing an entire browser (or any web platform host environment) is the sum of closing all of its top level browsing contexts and is an operation that, today, lives far outside the reach of specified behavior.

At least two other web platform features -- Beacons and `<a ping>` -- are intended to help developers avoid running their own application logic during shutdown. Neither feature requires browsers to run any particular code immediately during shutdown and both are "best effort" in major implementations today (despite what the specs might request). The [`HTMLAnchorElement`'s `ping` attribute](https://html.spec.whatwg.org/multipage/semantics.html#ping) sends a notice to the server regarding the anchor's navigation, and the [`sendBeacon` API](http://www.w3.org/TR/beacon/) allows for a [limited-size] payload, such as performance or analytic information, to be queued and relayed back to a server at a convenient time for the user agent.

These features address the desired reliable reporting in a best-effort way. They operate as late as possible in the life-cycle of the document, but use asynchronous techniques that are designed not to interfere or block navigation of a document nor shutdown of a browsing context. They also defer implementation details to UAs regarding the life-cycle of the browsing contexts. These are reasonable models to follow.

The major gap in providing opportunities to run arbitrary code (not declarative, canned behaviors) during browser shutdown is that there are no hooks to the life-cycle model of a browsing context spec'd anywhere in the web platform today. As cited in [issue 73](https://github.com/w3ctag/spec-reviews/issues/73#issuecomment-152110576), the unloading of a document is one possible place to trigger the operation, but it cannot be determined if this is the result of navigation (implying that the browsing context remains active) or closing of the browsing context itself. It may be possible to add hooks, however, as noted above, implementations are keen to avoid running any unnecessary code after the browsing context is committed to close. It's also unclear what context would execute the callbacks of such hooks in general. Must documents be left alive?

Given the desire to offload operations that delay navigation or shutdown into asynchronous and/or deferred actions, another related approach might be to design a "shutdown worker" which may be queued to start on navigation of a browsing context or launched at the user agent's earliest convenience (similar to the `sendBeacon` processing model). We leave such a design up to the interested reader but note that the upcoming [Background Sync](https://github.com/WICG/BackgroundSync/blob/master/explainer.md) work may provide a model.

Implementations are welcome to add triggers and hooks to run operations on shutdown of specific web platform environments, of course. It must be understood however, that many web platform environments may not offer the same opportunities; for example, implementations of the web platform that exist only embedded in silicon--they may be started when power is applied and stopped when power is removed. Other operating environments, especially resource-constrained environments like mobile phones may apply policies that constrain features like service workers or storage activity in order to save battery.

In conclusion, the TAG does not believe that a web-based feature should require executing steps in an environment that is already in the process of closing down as described above. In general, the TAG favors designs that promote asynchronous or deferred actions; in contrast, requiring run-at-close steps as requested would likely be synchronous in order to reliably work in such a scenario, and therefore not appropriate for the web platform.

---
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/spec-reviews/issues/73#issuecomment-171536298