Proposal: asynchronous event listeners

[domfarolino]

What is the issue with the DOM Standard?

I've heard chatterings in a few different places about interest in asynchronous event listeners on the platform, so I figured I'd file a bug here for some more centralized discussion. The problem: When some action happens on the web platform that results in firing events, all event listeners for that event are immediately, right then & there on the spot, without regard to the priority of the listener relative to surrounding tasks. It's entirely possible that developers wish to know about/respond to some events at a much lower priority than other competing tasks at around the same time. Currently there is no way to signal to the platform, that an event listener should be invoked asynchronously after the platform would ordinarily do so, saving the event listener's invocation for a less-busy/contentious time, in terms of task scheduling and execution.

Enabling this would let developers extend their existing task scheduling / prioritization logic to their event listeners as well. Something very rough along these lines can already be done today:

button.addEventListener('click', e => {
  if (mustDefer) {
    setTimeout(realClickHandler, kTimeout);
    // or…
    requestAnimationFrame(realClickHandler);
  }
});

…but it's pretty limited. First, it still involves immediately invoking user script in response to the event, so we don't actually avoid a big part of that cost. The fact that the queueing / deferral logic is handled immediately in userland is a missed performance opportunity — perhaps a large one? Second, it's not all that ergonomic, and is perhaps harder to schedule the readClickHandler relative to other userland tasks that follow a certain scheduling dynamic.

I wonder if there is an opportunity to integrate the Prioritized Task Scheduling API here. One option would be doing something as simple as passing in a task priority to addEventListener():

button.addEventListener('click', e => {
    // Do real stuff asynchronously…
    // e.preventDefault() does not work here❗
}, {priority: "user-visible"});

Related discussion: WICG/observable#74.

@chrishtr @mmocny @shaseley @mfreed7

[WebReflection]

FYI I've proposed to expose event.waitUntil when a listener is asynchronous as there's previous work on that within a Service Worker fetch listener ... and that didn't go well.

As possible workaround, we ended up polluting the addEventListener to make it possible to prevent the default (or stop propagation) wen a listener comes from a worker.

Basically if the options contains an invoke field which is a stopPropagation or preventDefault string, or an array with one or more methods to invoke, when the event triggers these methods are invoked.

This works well only if you know AOT you want to prevent that default or stop that (immediate) propagation. It cannot possibly work in any other scenario and it can't work conditionally neither (but that's an implementation detail/limitation).

[mmocny]

I wonder if there is an opportunity to integrate the Prioritized Task Scheduling API here. One option would be doing something as simple as passing in a task priority to addEventListener():

I like it!

I think this implies that each unique priority would be dispatched as a distinct (macro)task, and that the scheduler could defer lower priority event listeners as needed, perhaps even after rAF.

Would all event listeners at the same given priority still be coalesced into the same task? Or, if they are async now anyway, should they all be scheduled as if called with scheduler.postTask()?

---

FYI I've proposed to expose event.waitUntil when a listener is asynchronous

Interesting! I've made this suggestion before as well, though I wonder if the use case I had in mind was the same as what you suggested?

I think that waitUntil could be one useful way to express a lazy-loading controller for an event listener. Increasingly frameworks today support lazy-loading controllers/listeners, but rely on synchronous event capture and then later on synthetic event replay, to do so. This is inconvenient and lossy in many ways... though an ideal solution might need to be declarative.

(But, I don't quite see how waitUntil should help make the initial event dispatch async...)

[WebReflection]

(But, I don't quite see how waitUntil should help make the initial event dispatch async...)

example code I had in mind:

anything.addEventListener('name', (event) => {
  event.waitUntil(new Promise(async (res, rej) => {
    const thing = await (await fetch(permision)).text();
    if (thing === 'OK') {
      event.stopPropagation();
      event.preventDefault();
      return resolve();
    }
    reject();
  }));
});

This idea won't need any execution priority expectation, it would just flag that event as "unresolved" until whatever asynchronous thing needed to eventually keep going happens.

I hope this makes sense.

Original proposal + discussion: whatwg/html#9540

[mmocny]

That makes total sense to me, and overlaps with the "lazy-loaded event listener" use case I mentioned. It's just slightly orthogonal to the original proposal here.

(Not to say that all the async use cases shouldn't be discussed together)

[WebReflection]

@mmocny to clarify, I am 👍 on this proposal ... literally anything that will start tackling how to deal with async events, as every new API is async these days too, would be a great improvement over the current state. Anything would work to me and, to be honest, I find waitUntil thing ugly myself, my previous proposal was trying to simply "hack" around the fact there is some documentation and a previous case to consider around its existence ... if we could have a better approach that maybe one day will land in Service Worker too, even better 👋

[mmocny]

Here is one short list of use cases for what "async events" might mean to folks, each with potentially different feature requests:

• "lazy loading controllers"

  • You don't have the code to attach to addEventListener loaded yet, but the UI is already presented and the user could already interact.
  • You want to delay any events from starting to dispatch, perhaps until some fetch / script finishes loading, or alternatively you just want a better mechanism to capture and replay the event later.
  • Note: once the event listener is loaded, it becomes a normal synchronous event listener.
  • Note: the declarative UI might have a declarative fallback (e.g. link click or form submit) but the imperative event might be "better" if allowed to load. Perhaps a timeout decides when to dispatch the default action?

• "passive event dispatch"

  • This event listener needs to observe the event, but doesn't actually implement the core functionality of the event and doesn't need to be scheduled immediately and before next paint.
  • Already supported for various scroll events, and for specific features like Intersection Observer and some animation lifetime events, etc.
  • Easy to polyfill or workaround, as an opt-in, but might leave scheduling/performance opportunities on the table.
  • As a native feature, might be applied as a policy / intervention. For example, constraining a third party script to only be allowed to register passive listeners.
  • Note: {priority} seems to me to imply "passive" yet gives even more control.

• "async effects which follow the sync event"

  • The use case @WebReflection lists.
  • Might still want to be able to preventDefault etc from the async., e.g. form validation which needs a network hop first.
  • Might want other web platform features, like performance event timing, to measure all the way to the end of async effects.
  • (Potentially?) has some overlap with AsyncContext / Task Attribution

• "document unload" use cases

  • Today you can easily block the start of a navigation that would unload a document, but, once a document starts unloading there is a limited amount of time for script.
  • As a result, many scripts hook onto events and delay the default action (such as a link navigaton or form submit) from even starting, for fear of not having a change to observe the event at all when that event triggers document unload.
  • Perhaps we need a contract: This event listener is only passively attached to this event... but it should be "flushed" before unload. (Reminder: these scripts are already blocking unload start, anyway)

• "document loading" use cases

  • Related to lazy-loading controllers but less fine grained. We have blocking=rendering for first paint but we don't have a way to block all events on resources like script.
  • Very early interactions are racy, and the priority of event dispatch is unpredictably prioritized over async/defer scripts.

[WebReflection]

I don't know if this is useful extra use case or implementation detail, but:

Perhaps a timeout decides when to dispatch the default action?

I have worked with SerialPort API and discovered the transient activation standard which already works well on Chrome/ium browsers (at least) and it has a transient activation duration spec that might (maybe?) help this proposal forward.

[flackr]

• "async effects which follow the sync event"

  • Might still want to be able to preventDefault etc from the async., e.g. form validation which needs a network hop first.

Being able to arbitrarily delay (and as a result re-order) default actions could have pretty far reaching complexity and implications.

I suspect for security reasons we might need to have a limit on how long a default action could be delayed and still executed, this reminds me a bit some of the async user activation use cases and could be a better way to handle it (having a direct link from the event to the user-activation requiring API), though we likely still need to support the model we have today. @mustaqahmed

I think we'd have to look through the different default actions and figure out whether they make sense to be possible to be delayed. E.g. we probably don't want to delay the default action of touchdown starting a scroll, and preventing the touch from turning into compatibility gestures like click.

Similarly there may be groups of default actions which don't make sense to be re-ordered. E.g. delaying setting focus while still clicking on the element?

[WebReflection]

@flackr links to delayed activations is in my previous comment: #1308 (comment)

I agree some event doesn't want that activation but your gesture example is spot-on: the whole clicking is a delayed event, why can't that event await before landing the user into a different page or avoid submitting that form already?

So 👍 to me about defining non-async-friendly events (I think these are an easy/small list related to mouse or touch movements or scrolling and not much else) and those that could wait a transient time before firing out of the blue.

The fact transient events exist in the first place should be a strong indication the synchronous API defined "ages ago" when no async existed in the first place might need some modernization for current APIs which are 99% of the time asynchronous anyway.

[esprehn]

I like the spirit of this, though I think you'd need to make the events uncancellable per the top comment and the default action happen in the past for this to not introduce a lot of engine complexity.

I think at least in Chrome input (ex. click) is aligned to the frame boundaries at "user-visible" priority because of how it flows through the compositor. Other events happen at animation frame timing ("user-blocking") too:

https://source.chromium.org/search?q=%22enqueueAnimationFrameEvent(%22

https://source.chromium.org/search?q=%22-%3EEnqueuePerFrameEvent(%22&sq=

So in most cases calling requestAnimationFrame from inside those events won't help except to try to batch work differently.

If you spec that the browser always posts a fresh task even if you're already at the same priority that would move the click later in time.

I suspect the most expensive part of clicking is the hit test which you can't avoid, but maybe those 3 lines of script add up. I don't see any harm in letting folks request a postTask priority like Dominic is suggesting though.