Does accessing ExtendableEvent's extend lifetime promises race?

[jungkees]

@annevk pointed out there can be a race in accessing ExtendableEvent’s extend lifetime promises:
72315b9#commitcomment-18283685

I think it's a fair point as now e.waitUntil(f) can be called async.

[jakearchibald]

Feels like Set <var>extendLifetimePromises</var> to a copy of should go before the parallel steps, but If the length of <var>extendLifetimePromises</var> does not equal also needs to be in the service worker thread, so I guess a task needs to be queued for that?

[jakearchibald]

F2F:

• Set <var>extendLifetimePromises</var> to a copy of happening before parallel doesn't seem to be an issue, since it's only ever going to be more promises, which we want to catch
• We need to look at the spec language for "waiting for all" to see if it queues a microtask

[jungkees]

Having discussed with @annevk, I will first have to move the "When dispatching an event e that uses the ExtendableEvent interface" steps to right after the actual (dispatching) actions. I'll define some general wrapper that dispatches the event and run these steps, and make it invoked from Handle Fetch and Handle Functional Events.

The OP still should be addressed here.

[jungkees]

@domenic suggested we use a reference count approach over the current promise-copying-and-checking one. Will try to come up with it.

[jungkees]

Addressed #931 (comment): c2a518b.

Addressed #931 (comment): 6c1f3fe.