Capture the hasListener consensus

[slightlyoff]

As per today's f2f discussion at Mozilla, we've decided on filtering event dispatch for the life of an active handler based on the list of event handlers which are registered in the SW global.

E.g., a SW without an onfetch handler will never ever be sent a fetch event:

// because oninstall is registered synchronously, it will be dispatched
self.oninstall = function(e) {
  // no fetch events will ever be sent to this SW
  self.onfetch = function(e) { ... };
};
// this SW will also be sent sync events
self.onsync = function(e) { ... };

The exact spec language will need to look at the list of registered handlers as the very first microtask-end task during the initial evaluation of the SW script. Subsequent boot-ups of the SW will only be triggered by the list of events captured as a result of that first eval. Updates (new oninstall chances) are the only time the list of event handlers will be re-litigated. E.g., the list of events you register for is fixed per-version by the events you register at the top-level the very first time.

[tabatkins]

Can you just say "when a listener is registered for an X event, record that the SW is listening to X events", and only update that record during install/update callbacks?

[jakearchibald]

@tabatkins That involves wrapping addEventListener in something that does the recording. I'm fine with that, but others not-so.

[annevk]

Not everyone is happy about doing this: http://krijnhoetmer.nl/irc-logs/whatwg/20140409#l-34

It seems @Hixie and @tabatkins are talking a little bit past each other there. I'm pretty sure @Hixie is only ok with overloading onfetch, not with addEventListener. (The latter would require an explicit API call for opting in.)

[slightlyoff]

I'd also like to avoid overriding addEventListener. It's possible to vend an ES6 proxy for the global and observe calls, but it seems simpler to retreat into bookkeeping magic and note that events with listeners added at the end of evaluation will be captured in the record. We don't need to enumerate how this happens right now except to say that there is an internal record and we do reference it.

[KenjiBaheux]

@slightlyoff @jakearchibald this needs-spec issue hasn't been updated in a while and a quick read of the spec didn't reveal anything relevant. Is this issue still current?

[annevk]

#445 has a different approach to this.

[KenjiBaheux]

Thanks, let's see how the discussion spans out on #445