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

> 1. Do we have tests.

I don't think we have tests for this yet. @mattto, please correct me if I'm wrong.

> 2. Can we remove the exception at this point.
> 3. Should we limit this practice somehow. E.g., require an opt-in other than an event listener for new "functional events".

I have an idea:

A `ServiceWorkerGlobalScope` object has its [associated service worker](https://w3c.github.io/ServiceWorker/#serviceworkerglobalscope-service-worker). When the [add an event listener](https://dom.spec.whatwg.org/#add-an-event-listener) is called with a `ServiceWorkeGlobalScope` object, we can record the event's type to the service worker's [set of event types to handle](https://w3c.github.io/ServiceWorker/#dfn-set-of-event-types-to-handle) item instead of throwing an exception. For functional events including fetch, we can check the [set of event types to handle] to start the service worker. In this way, we wouldn't need the [has ever been evaluated flag](https://w3c.github.io/ServiceWorker/#dfn-has-ever-been-evaluated-flag).

That change would allow us to add event listeners in async tasks. For instance,

```js
self.addEventListener('push', e => {
  self.onfetch = e => {
    // A push event will add this fetch listener.
  };
});
```

Also, custom events will work without any constraints within the lifetime of a service worker though we won't allow the custom events to start off the service worker.

Thoughts?

-- 
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-374135167