Increase the lifetime of Navigation Preload related objects.

third_party/WebKit/LayoutTests/http/tests/serviceworker/navigation-preload/resources/abort-when-responded-worker.js

Index: third_party/WebKit/LayoutTests/http/tests/serviceworker/navigation-preload/resources/abort-when-responded-worker.js
diff --git a/third_party/WebKit/LayoutTests/http/tests/serviceworker/navigation-preload/resources/abort-when-responded-worker.js b/third_party/WebKit/LayoutTests/http/tests/serviceworker/navigation-preload/resources/abort-when-responded-worker.js
new file mode 100644
index 0000000000000000000000000000000000000000..27c53cd78af59602c253b50f8a8fd741af06ef9f
--- /dev/null
+++ b/third_party/WebKit/LayoutTests/http/tests/serviceworker/navigation-preload/resources/abort-when-responded-worker.js
@@ -0,0 +1,19 @@
+self.addEventListener('activate', event => {
+    event.waitUntil(
+        self.registration.navigationPreload.enable());
+  });
+
+var preload_resolve;
+var preload_promise = new Promise(r => { preload_resolve = r; });
+
+self.addEventListener('fetch', event => {
+    event.waitUntil(event.preloadResponse.then(
+        r => preload_resolve('RESOLVED'),
+        e => preload_resolve('REJECTED: ' +  e.toString())));

[falken, 2017/01/19 01:27:37]

Does the spec require this? It seems reasonable for an implementation to still
wait on |preloadResponse| and resolve it normally since the JS called
waitUntil(preloadResponse). The JS could still do something like put it in the
cache for a next fetch.

If we land this, I think it should be a chromium test unless we think the spec
will require rejecting the preload.

+    event.respondWith(new Response('OK'));
+  });
+
+self.addEventListener('message', event => {
+    event.waitUntil(
+      preload_promise.then(result => event.source.postMessage(result)));
+  });