Re: [w3c/ServiceWorker] Recovering from start failures (#1503)

https://w3c.github.io/ServiceWorker/#run-service-worker-algorithm returns _failure_ or the [Completion](https://tc39.es/ecma262/#sec-completion-record-specification-type) returned from https://html.spec.whatwg.org/multipage/webappapis.html#run-a-classic-script.

If a runtime error occurs, it returns a Completion containing the error (an "abrupt completion").

If the script couldn't run due to an internal error (the browser couldn't run the worker to completion), it returns _failure_.

Currently the spec says that _failure_ results in a network error, but on an uncaught runtime error the service worker is considered running and it dispatches the fetch event as usual.

Only the Update algorithm cares about runtime errors at step 18:

17. Let runResult be the result of running the Run Service Worker algorithm with worker and forceBypassCache.
18. If runResult is failure or an abrupt completion, then:
18.1 Invoke Reject Job Promise with job and TypeError.

Chrome is doing fallback in both cases, whereas the spec says only do it on runtime error. I agree the behavior is a bit magical. The fallback was done as a safeguard.

We should also consider the case like when the user disables JS. In this case, I believe Run Service Worker will return _failure_. We probably want to "fallback" in this case though.


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1503#issuecomment-581742194