From c839e333667f5a2234f9ec1e5540a60199937997 Mon Sep 17 00:00:00 2001 From: Jake Archibald Date: Thu, 6 Nov 2014 12:36:08 +0000 Subject: [PATCH] Replacing InstallEvent.replace with skip waiting flag - TODO: make an API to this --- service_worker.js | 12 ----------- service_worker.ts | 12 ----------- spec/service_worker/index.html | 39 +++------------------------------- 3 files changed, 3 insertions(+), 60 deletions(-) diff --git a/service_worker.js b/service_worker.js index a738a235..bd2b04b6 100644 --- a/service_worker.js +++ b/service_worker.js @@ -52,15 +52,6 @@ var InstallEvent = (function (_super) { _super.apply(this, arguments); this.activeWorker = null; } - // Ensures that the worker is used in place of existing workers for - // the currently controlled set of window instances. - // NOTE(TOSPEC): this interacts with waitUntil in the following way: - // - replacement only happens upon successful installation - // - successful installation can be delayed by waitUntil, perhaps - // by subsequent event handlers. - // - therefore, replace doesn't happen immediately. - InstallEvent.prototype.replace = function () { - }; return InstallEvent; })(ExtendableEvent); @@ -337,9 +328,6 @@ var FetchEvent = (function (_super) { // Design notes: // - Caches are atomic: they are not complete until all of their resources are // fetched -// - Updates are also atomic: the old contents are visible until all new -// contents are fetched/installed. -// - Caches should have version numbers and "update" should set/replace it // This largely describes the current Application Cache API. It's only available // inside worker instances (not in regular documents), meaning that caching is a // feature of the event worker. This is likely to change! diff --git a/service_worker.ts b/service_worker.ts index 01099ed0..ef98d0ae 100644 --- a/service_worker.ts +++ b/service_worker.ts @@ -113,15 +113,6 @@ class ExtendableEvent extends _Event { class InstallEvent extends ExtendableEvent { activeWorker: ServiceWorker = null; - - // Ensures that the worker is used in place of existing workers for - // the currently controlled set of window instances. - // NOTE(TOSPEC): this interacts with waitUntil in the following way: - // - replacement only happens upon successful installation - // - successful installation can be delayed by waitUntil, perhaps - // by subsequent event handlers. - // - therefore, replace doesn't happen immediately. - replace(): void {} } interface InstallEventHandler { (e:InstallEvent); } @@ -496,9 +487,6 @@ class FetchEvent extends _Event { // Design notes: // - Caches are atomic: they are not complete until all of their resources are // fetched -// - Updates are also atomic: the old contents are visible until all new -// contents are fetched/installed. -// - Caches should have version numbers and "update" should set/replace it // This largely describes the current Application Cache API. It's only available // inside worker instances (not in regular documents), meaning that caching is a diff --git a/spec/service_worker/index.html b/spec/service_worker/index.html index b64b3577..7b55b145 100644 --- a/spec/service_worker/index.html +++ b/spec/service_worker/index.html @@ -126,6 +126,7 @@

Service Worker

A service worker has an associated script url (a URL).

A service worker has an associated containing service worker registration (a service worker registration), which contains itself.

A service worker is dispatched a set of lifecycle events, install and activate, and functional events including fetch.

+

A service worker has an associated skip waiting flag. Unless stated otherwise it is unset.

Lifetime

@@ -587,7 +588,7 @@

Events

controllerchange Event - The document's associated service worker registration acquires a new active worker. (See step 1.8 of the Activate algorithm. When the activation of the service worker registration is triggered by replace() method call within the event handler of the install event, navigator.serviceWorker.controller immediately reflects the active worker as the service worker that controls the document.) + The document's associated service worker registration acquires a new active worker. (See step 1.8 of the Activate algorithm. The skip waiting flag of a service worker causes activation of the service worker registration to occur while clients are using the service worker registration, navigator.serviceWorker.controller immediately reflects the active worker as the service worker that controls the document.) error @@ -1436,27 +1437,12 @@

InstallEvent

[Constructor(DOMString type, optional InstallEventInit eventInitDict), Exposed=ServiceWorker] interface InstallEvent : ExtendableEvent { readonly attribute ServiceWorker? activeWorker; - void replace(); }; dictionary InstallEventInit : EventInit { ServiceWorker activeWorker; }; - -

Each event using InstallEvent interface has the following associated flag that is initially unset: -

- - -

event.replace()

- -

event.replace() method interacts with event.waitUntil(f) method. Successful installation can be delayed by event.waitUntil(f). Replacement only happens upon successful installation. That is, replacement of the active worker (if any) by invoking event.replace() method is not immediate, but it may occur as soon as the event's event handler completes its execution which is extended by event.waitUntil(f).

- -

replace() method must set the activate immediate flag.

- - @@ -1969,7 +1955,6 @@

Install

  1. Let installFailed be false.
    2. -
  2. Let activateImmediate be false.
  3. CheckPriority: If the value of the top element of [[InstallationQueue]] matches timeStamp, then:
    1. Pop the top element from [[InstallationQueue]].
      2. @@ -2028,11 +2013,6 @@

      Install

    4. -
  4. If event's activate immediate flag is set, then: -
      -
    1. Set activateImmediate to true.
      2. -
    -
@@ -2088,21 +2068,8 @@

Install

  • Unset registration's uninstalling flag.
    • -
  • If activateImmediate is true, then: +
  • If registration's waiting worker's skip waiting flag is set, then:
      -
    1. For each service worker client client whose client url matches registration's scope url: -
        -
      1. Let exitingWorker be the active worker that controls client.
        2. -
      2. If exitingWorker is not null, then: -
          -
        1. Wait for exitingWorker to finish handling any in-progress requests. -
          2. -
        2. Terminate exitingWorker.
          3. -
        3. Run the Update State algorithm passing exitingWorker and redundant as the arguments.
          4. -
        -
        3. -
      -
    2. Run Activate algorithm, or its equivalent, passing registration as the argument.
    3. Abort these steps.