clarify that manually constructed ExtendableEvent objects may not extend lifetime via waitUntil()

[wanderview]

Currently its possible to do this in the spec:

let e = new ExtendableEvent('foo');
e.waitUntil(new Promise());

By default the extensions allowed flag is set, so this does not throw an InvalidStateError.

We should be clear, though, that this does not actually extend the lifetime of the SW. Currently the spec is written in a way that suggests that this might imbue some keep-alive budget to the SW.

[wanderview]

I would also be happy to make manually constructed ExtendableEvent objects unset extensions allowed flag.

[wanderview]

I think we also used to have something that prevented waitUntil() outside of a dispatch, but I don't see that any more. Thats a minor issue, though, since the the script can call self.dispatchEvent().

[wanderview]

FWIW, we are going to throw InvalidStateError in this case. Its easier to open this up to not throw if we need that behavior for some reason.

[stefhak]

To put this in context, I do, to emulate background sync on Firefox, periodically check if navigator.onLine is true, and when it is I fire an extendable event:

let e = new ExtendableEvent('sync');
e.tag = 'some_tag';
if (navigator.onLine)
    self.dispatchEvent(e);

My event handler looks like:

self.addEventListener('sync', (evt) => {
    if (evt.tag == 'some_tag') {
        evt.waitUntil(doStuff());
    }
});

where evt.waitUntil is taken from some Background sync tutorial. I understand it would not have any effect with my emulated background sync, but will it with the real background sync? Is that specified anywhere?

[jakearchibald]

I think #980 (comment) would fix this too.

[jakearchibald]

To discuss: Should we spec #980 (comment), and is this v1?

[wanderview]

Even if we spec the solution in #980, I don't think it should apply to manually constructed events.

[jakearchibald]

F2F: When we spec #980, the example in the OP shouldn't allow waitUntil, as if promises have been previously passed & all settled.

[jungkees]

I think we may want to use event.isTrusted to check if the event is a synthetic object instead of checking pending promises count here. @annevk, can we ensure with .isTrusted == false if an event is a synthetic event?

[annevk]

What is mentioned in OP should already throw since the dispatch flag is not set.

But yeah, it seems reasonable to also check the isTrusted attribute (internal slot at some point). Not entirely convinced that's the best way, but that should work.