Re: [w3c/ServiceWorker] Proposal: Allow addEventListener/removeEventListener for 'fetch' to called at anytime (#1195)

I'm suggesting that addEventListener and removeEventListener for `fetch` would update the internal service worker registration information to track `has_fetch_handler`. During this in-flight fetches may or may not go through the fetch handler so it's a bit racy.

Right now, at least as implemented in Chrome, fetch requests block on the completion of the `activate` handler. If a service workers wants to guarantee that navigate/all fetches are handled it would only need to call addEventListener before the completion of `activate`. This would provide strictly better behavior that what is offered from w3c/ServiceWorker#718 and would resolve the concerns in whatwg/dom#371 by not requiring that change.

Facebook is seeing that requests for non-navigation resources that are served from the HTTP cache are significantly slower when there's an activate `fetch' handler. We've also seen a large performance improvement by replacing navPreload `fetch` handler for push-only SW with the install time `has_fetch_handler` tracking introduced by w3c/ServiceWorker#718. This issue would let us fix this at run-time and wouldn't require this weird error throw behavior for addEventListener.

-- 
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/1195#issuecomment-331324959