Repository navigation
Better hooks for functional events #1808
Description
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.
Activity
yoshisatoyanagisawa commentedon Nov 26, 2025
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
postDispatchStepsis intended for, but this is not explicit, which makes the specification harder to follow.Furthermore, the current algorithm checks
has showNotification() been successfully invokedregardless of whether the event'swaitUntilpromises 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 Eventalgorithm 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 likeAddEventListenerOptionsinaddEventListener()the kind of solution you have in mind?yoshisatoyanagisawa commentedon Nov 26, 2025
Just to note to myself.
The latest algorithm change has been introduced in #1199, which contains the list of specifications using the function.
annevk commentedon Nov 26, 2025
Named parameters are more like https://dom.spec.whatwg.org/#concept-node-clone. See also https://infra.spec.whatwg.org/#algorithm-params.
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 commentedon Nov 26, 2025
I am not fully confident but,
Is #1809 the named parameters you mean?
For
I assumed that you might want the ServiceWorker specification support to let the caller know promise resolve/reject from the following sentence:
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?