Better hooks for functional events

[annevk]

Most specifications that define functional events don't seem to fire them with the arguments Service Workers prescribes. In particular postDispatchSteps is often rather hand-wavy.

And given that some of the arguments are optional, but none are named (see Infra), it's rather unclear how to properly do this.

On top of that specifications might want to do something only after the events extension period is over, and perhaps do different things depending on whether the promise resolves or rejects. Doing this cleanly is somewhat murky at the moment. In Push API for instance we simply wait for some state to flip while in parallel: https://w3c.github.io/push-api/#dfn-fire-a-push-event

This should be organized a bit better.

[yoshisatoyanagisawa]

I've looked at the Push API specification in light of this issue.

The "run the following steps in parallel" section in the Push API seems to be what postDispatchSteps is intended for, but this is not explicit, which makes the specification harder to follow.

Furthermore, the current algorithm checks has showNotification() been successfully invoked regardless of whether the event's waitUntil promises resolve or reject. I believe this check should ideally only occur on successful resolution. This highlights the need for a mechanism that allows the caller to more easily differentiate between a promise's fulfillment and rejection.

I also agree that the Fire Functional Event algorithm would be much clearer if it used named arguments via a single dictionary object. Do you have any examples in mind? Is the dictionary-based approach like AddEventListenerOptions in addEventListener() the kind of solution you have in mind?

[yoshisatoyanagisawa]

Just to note to myself.
The latest algorithm change has been introduced in #1199, which contains the list of specifications using the function.

[annevk]

Named parameters are more like https://dom.spec.whatwg.org/#concept-node-clone. See also https://infra.spec.whatwg.org/#algorithm-params.

Furthermore, the current algorithm checks has showNotification() been successfully invoked regardless of whether the event's waitUntil promises resolve or reject.

I'm not sure what you mean? It only updates notificationResult to a non-failure value when the promises resolve successfully. The language is a bit hand-wavy though.

[yoshisatoyanagisawa]

I am not fully confident but,
Is #1809 the named parameters you mean?

For

Furthermore, the current algorithm checks has showNotification() been successfully invoked regardless of whether the event's waitUntil promises resolve or reject.

I assumed that you might want the ServiceWorker specification support to let the caller know promise resolve/reject from the following sentence:

On top of that specifications might want to do something only after the events extension period is over, and perhaps do different things depending on whether the promise resolves or rejects.

I supposed that you want "Wait for all of the promises in the extend lifetime promises of dispatchedEvent to resolve." to be done by the ServiceWorker specification.
Can I ask how the ideal caller will be?