ServiceWorker: Fix messed registration attributes on ServiceWorkerGlobalScope

third_party/WebKit/LayoutTests/http/tests/serviceworker/ServiceWorkerGlobalScope/resources/registration-attribute-newer-worker.js

Index: third_party/WebKit/LayoutTests/http/tests/serviceworker/ServiceWorkerGlobalScope/resources/registration-attribute-newer-worker.js
diff --git a/third_party/WebKit/LayoutTests/http/tests/serviceworker/ServiceWorkerGlobalScope/resources/registration-attribute-newer-worker.js b/third_party/WebKit/LayoutTests/http/tests/serviceworker/ServiceWorkerGlobalScope/resources/registration-attribute-newer-worker.js
new file mode 100644
index 0000000000000000000000000000000000000000..63fd6c10eb359bf27c427783c469513924689a78
--- /dev/null
+++ b/third_party/WebKit/LayoutTests/http/tests/serviceworker/ServiceWorkerGlobalScope/resources/registration-attribute-newer-worker.js
@@ -0,0 +1,30 @@
+var results = [];

[falken, 2015/11/19 01:29:22]

A lot of our tests do this, but I think we shouldn't rely on global state
surviving between events in a W3C test. Can you add a TODO? Or I think you may
be able to restructure the test to move the expectations into the worker, so it
cries immediately when something fails?

[nhiroki, 2015/11/19 09:02:54]

I agree that we should avoid global states. I'm thinking of some options...


1) having assertions in the worker side
As I commented on registration-attribute-worker.js, worker-side assertion
failures cannot be shown on the result page and are handled as timeout. This
could make debugging hard, so I'd prefer to keep them in the page side if
possible.

2) keeping results in storage (CacheStorage or IDB?)
Regarding CacheStorage, it might be difficult to wait for storing all results on
the message event because it involves multiple async operations (opening the
cache, putting results, ...) and some of events are not waitable (not
ExtendableEvent).

Regarding IDB, we could handle it with transaction, but it seems like
overkill...

3) sending results to the page on each event
On evaluation phase, posting messages via Client object could be the only way to
communicate to the page like following code:

  // worker.js
  function record(event_name) {
    var result = event_name + '...';
    self.clients.matchAll({includeUncontrolled: true})
      .then(function(clients) { clients[0].postMessage(result); });
  }

but currently clients.matchAll() never returns on the evaluation phase (see
issue 533130) and this is not feasible...


IMO, leaving TODO comments for now and working on (3) after the issue is fixed
would be the simplest solution. What do you think?

+
+function stringify(worker) {
+  return worker ? worker.scriptURL : 'empty';
+}
+
+function record(event_name) {
+  results.push(event_name);
+  results.push('  installing: ' + stringify(self.registration.installing));
+  results.push('  waiting: ' + stringify(self.registration.waiting));
+  results.push('  active: ' + stringify(self.registration.active));
+}
+
+record('evaluate');
+
+self.registration.addEventListener('updatefound', function() {
+    record('updatefound');
+    var worker = self.registration.installing;
+    self.registration.installing.addEventListener('statechange', function() {
+        record('statechange(' + worker.state + ')');
+      });
+  });
+
+self.addEventListener('install', function(e) { record('install'); });
+
+self.addEventListener('activate', function(e) { record('activate'); });
+
+self.addEventListener('message', function(e) {
+    e.data.port.postMessage(results);
+  });