Re: [whatwg/dom] Nerfing all events on all event targets in a serviceworker after initial script evaluation seems odd (#371)

> I don't really see a discussion.

Basically this: https://github.com/w3c/ServiceWorker/issues/718. The goal was to deterministically detect if a SW opted in to certain functional events. We didn't want to override `addEventListener` for this, was trying to introduce an API to disable fetch, etc. But finally determined to store the set of event types the SW script deterministically declares during the initial execution - only possible by a successful update through the first run in [Update](https://w3c.github.io/ServiceWorker/#update-algorithm) algorithm step 9.6. And we added the condition to `addEventListener()` that checks _has ever been evaluated flag_. We need to fix this to check it only on `ServiecWorkerGlobalScope` as mentioned.

> it introduced inconsistent behavior between addEventListener("fetch", ...) and setting onfetch...

This is https://github.com/w3c/ServiceWorker/issues/1004. `onfetch` needs the same behavior.

> OK, but you're doing this for all events, including random made-up ones the service worker script itself decides to fire. I don't see why this is at all reasonable.

Synthetic events do not spin off SW. Note that only SW lifecycle events and functional events run SW. `fetch` event dispatch is defined by SW's [Handle Fetch](https://w3c.github.io/ServiceWorker/#on-fetch-request-algorithm) and other functional events should extend SW spec and dispatch events by invoking [Handle Functional Event](https://w3c.github.io/ServiceWorker/#handle-functional-event-algorithm). (Also see https://w3c.github.io/ServiceWorker/#extensibility.)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/371#issuecomment-259695860