Bug 1506429 [wpt PR 14016] - Update to new ServiceWorker spec link, a=testonly
authorCYBAI <cyb.ai.815@gmail.com>
Tue, 13 Nov 2018 13:41:55 +0000
changeset 502802 dd41dafb427ed85ddfeeecf4795ef387a689ca72
parent 502801 4500e9b5229f1c21901813d2e12aac85a9e20705
child 502803 2da88ffb958837812826c793afee7fc83ff21767
push id10290
push userffxbld-merge
push dateMon, 03 Dec 2018 16:23:23 +0000
treeherdermozilla-beta@700bed2445e6 [default view] [failures only]
perfherder[talos] [build metrics] [platform microbench] (compared to previous push)
bugs1506429, 14016
first release with
nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
last release without
nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
Bug 1506429 [wpt PR 14016] - Update to new ServiceWorker spec link, a=testonly Automatic update from web-platform-testsUpdate to new ServiceWorker spec link -- wpt-commits: 926d722bfc83f3135aab36fddc977de82ed7e63e wpt-pr: 14016
--- a/testing/web-platform/tests/docs/_writing-tests/testharness-api.md
+++ b/testing/web-platform/tests/docs/_writing-tests/testharness-api.md
@@ -429,17 +429,17 @@ when:
 This behaviour can be overridden by setting the `explicit_done` property to
 true in a call to `setup()`. If `explicit_done` is true, the test harness will
 not assume it is done until the global `done()` function is called. Once `done()`
 is called, the two conditions above apply like normal.
 Dedicated and shared workers don't have an event that corresponds to the `load`
 event in a document. Therefore these worker tests always behave as if the
 `explicit_done` property is set to true. Service workers depend on the
 event which is fired following the completion of [running the
 ## **DEPRECATED** Generating tests ##
 There are scenarios in which is is desirable to create a large number of
 (synchronous) tests that are internally similar but vary in the parameters
 used. To make this easier, the `generate_tests` function allows a single
@@ -605,17 +605,17 @@ Here's an example that uses `window.open
 The argument to `fetch_tests_from_window` is any [`Window`](https://html.spec.whatwg.org/multipage/browsers.html#the-window-object)
 capable of accessing the browsing context as either an ancestor or opener.
 ## Web Workers ##
 The `testharness.js` script can be used from within [dedicated workers, shared
 workers](https://html.spec.whatwg.org/multipage/workers.html) and [service
 Testing from a worker script is different from testing from an HTML document in
 several ways:
 * Workers have no reporting capability since they are running in the background.
   Hence they rely on `testharness.js` running in a companion client HTML document
   for reporting.
@@ -632,17 +632,17 @@ several ways:
   timeout](#harness-timeout) section).
 * Dedicated and shared workers don't have an equivalent of an `onload` event.
   Thus the test harness has no way to know when all tests have completed (see
   [Determining when all tests are
   complete](#determining-when-all-tests-are-complete)). So these worker tests
   behave as if they were started with the `explicit_done` option. Service
   workers depend on the
-  [oninstall](https://slightlyoff.github.io/ServiceWorker/spec/service_worker/index.html#service-worker-global-scope-install-event)
+  [oninstall](https://w3c.github.io/ServiceWorker/#service-worker-global-scope-install-event)
   event and don't require an explicit `done` call.
 Here's an example that uses a dedicated worker.
@@ -669,17 +669,17 @@ done();
 fetch_tests_from_worker(new Worker("worker.js"));
 The argument to the `fetch_tests_from_worker` function can be a
 a [`SharedWorker`](https://html.spec.whatwg.org/multipage/workers.html#shared-workers-and-the-sharedworker-interface)
-or a [`ServiceWorker`](https://slightlyoff.github.io/ServiceWorker/spec/service_worker/#service-worker-obj).
+or a [`ServiceWorker`](https://w3c.github.io/ServiceWorker/#serviceworker-interface).
 Once called, the containing document fetches all the tests from the worker and
 behaves as if those tests were running in the containing document itself.
 `fetch_tests_from_worker` returns a promise that resolves once all the remote
 tests have completed. This is useful if you're importing tests from multiple
 workers and want to ensure they run in series: