15:04:51 RRSAgent has joined #async-event-listeners 15:04:55 logging to https://www.w3.org/2024/09/25-async-event-listeners-irc 15:04:55 RRSAgent, do not leave 15:04:56 RRSAgent, make logs public 15:04:57 Meeting: Discussion for Proposal: asynchronous event listeners 15:04:57 Chair: Michal Mocny, Dominic Farolino 15:04:57 Agenda: https://github.com/w3c/tpac2024-breakouts/issues/101 15:04:57 Zakim has joined #async-event-listeners 15:04:58 Zakim, clear agenda 15:04:58 agenda cleared 15:04:58 Zakim, agenda+ Pick a scribe 15:04:59 agendum 1 added 15:04:59 Zakim, agenda+ Reminders: code of conduct, health policies, recorded session policy 15:04:59 agendum 2 added 15:04:59 Zakim, agenda+ Goal of this session 15:05:00 agendum 3 added 15:05:00 Zakim, agenda+ Discussion 15:05:00 agendum 4 added 15:05:00 Zakim, agenda+ Next steps / where discussion continues 15:05:02 agendum 5 added 15:05:03 tpac-breakout-bot has left #async-event-listeners 21:34:26 mmocny has joined #async-event-listeners 21:36:06 Document: https://github.com/mmocny/proposal-async-event-listeners 23:00:29 benoit_ has joined #async-event-listeners 23:00:49 Scott has joined #async-event-listeners 23:00:58 asully has joined #async-event-listeners 23:00:58 flackr has joined #async-event-listeners 23:01:26 noamr has joined #async-event-listeners 23:01:31 present+ 23:01:47 guohuideng has joined #async-event-listeners 23:02:23 mmocny has joined #async-event-listeners 23:02:34 https://github.com/mmocny/proposal-async-event-listeners 23:02:44 Proposal: https://github.com/whatwg/dom/issues/1308 23:02:50 github-bot, take up https://github.com/whatwg/dom/issues/1308 23:03:01 siye has joined #async-event-listeners 23:03:06 Scribenick: flackr 23:03:15 ScribeNick: flackr 23:03:58 mmocny: this is a discussion around ideas for 5 areas worthy of discussing. The bulk of the conversation could be for the first proposal but I wanted to seed the rest 23:04:32 noamh has joined #async-event-listeners 23:04:55 ayu has joined #async-event-listeners 23:04:58 mmocny: [reads from slide] 23:05:09 aykut has joined #async-event-listeners 23:06:07 mmocny: There's a large lack of support for passive listeners. When some action happens, all event listeners are immediately dispatched 23:06:36 mmocny: When I click button, the counter increases value and does some expensive work 23:06:44 mmocny: My component isn't bad, something else is blocking the update 23:06:48 smaug has joined #async-event-listeners 23:07:20 mmocny: Developers often wish to respond to events at some lower priority without blocking paint. There's currently no way to signal to the platform. There's many patterns (e.g. double raf) to try to do this 23:07:43 mustaq has joined #async-event-listeners 23:07:43 mmocny: Many listeners don't need to do any work to implement the default action 23:08:23 mmocny: common example, cookie consent dialogs have many things that follow the click, e.g. dialog disappears, records choice. There's a case study where one cookie response provider saw an improvement of ??% by doing this 23:09:06 mmocny: another idea is passive events. click events only dispatch non-passively even if you add a passive listener today. But if you polyfill this, you can delay expensive work 23:09:53 mmocny: Some differences, passive events can't preventDefault. It can be easy to polyfill, but relying on polyfills makes it less accessible and less used in practice. Native impls might have some opportunities to improve perf. We might also have an opportunity for interventions, e.g. some script is only allowed to listen passively 23:10:35 mmocny: an extension is to pass a priority. Right now, the priority is implicitly very high but if the dev knows priority is low maybe the dev could tell the UA 23:11:00 mmocny: some apis have noticed this and work around it, e.g. beforetoggle and toggle for popover 23:11:09 nathan has joined #async-event-listeners 23:11:22 mmocny: beyond UI events, there are other apis like IntersectionObserver which are inherently async, perhaps others could be 23:11:34 bas: why passive? why not async? 23:11:47 mmocny: any name you want. I picked this because passive exists 23:12:15 mmocny: this was a prior choice made for scrolling, to allow devs to declare they don't need to prevent the event 23:12:38 dom: since it's more about the effect that caused the event, that's why passive was chosen whereas async is ambiguous (microtask) 23:13:26 mmocny: there are risks with deferring work because of unloads. You could attach listeners for every link click, you could block navigation by adding expensive work on click 23:13:50 mmocny: worse yet, it prevents the start of any network request, speculation rules address some of this, but the issue is that at any point you could prevent the nav from happening 23:13:59 mmocny: a nice script might choose to yield or add a passive listener to avoid this 23:14:16 mmocny: however, once you do this, if the document unloads there's a very limited time to run your script, the effect could get dropped 23:14:29 mmocny: [shows demo of this] 23:14:59 mmocny: we know from lots of people that tried to be nice and yield they saw a decreased reliability and went back to blocking the nav 23:15:30 mmocny: maybe we need assurances that tasks are flushed before unload. If you task could already have blocked the nav, and you choose to yield, maybe we can ensure we run them before unload 23:15:58 mmocny: there is a pattern, idleUntilUrgent, that does this using doc lifecycle events 23:16:28 mmocny: scott presented an api which could possibly have something like runBeforeUnload 23:16:59 dom: with idleUntilUrgent, are we guaranteeing the task will run? If the task takes forever or there's 200 tasks before it we want to guarantee it succeeds/ 23:17:18 mmocny: correct, these scripts are currently guaranteed to run, we'd like to give them a lesser guarantee but some assurance that we will try to run them 23:17:42 mmocny: there are reasons to block click events that might still be there, but most could likely do the nice thing 23:18:10 dom: is there any diff between please before unload and having event handler run immediately and schedule the action in the unload listener? 23:18:48 mmocny: not sure, there are reasons we motivate people not to do things before unload, like prevents bfcache, this could also run before unload 23:18:59 dom: so it's like please run when idle or at worst before unload 23:19:15 mmocny: right, it lets you be low priority before unload, then guaranteeing 23:19:54 mmocny: there is a desire to track a string of async events. some sites create concepts to track groups of work 23:20:09 mmocny: support for passive events might add to this problem, you might have many actions arbitrarily scheduled 23:20:16 mmocny: maybe we should support tracking completion of effect 23:20:29 mmocny: developers have asked for this, state of event listener dispatch, etc 23:20:53 mmocny: there's also a string of projects to track scheduled work, task attribution, aync ?? 23:21:27 mmocny: we could have a TaskController, Finalize Registry 23:21:44 mmocny: some folks have asked for preventDefault support. Right now you have to decide in the synchronous event whether to preventDefault 23:22:02 mmocny: this can be difficult, right now you have to preventDefault always and then recreate the default action 23:22:28 mmocny: some libraries debounce all events, with the real listeners delayed by one anim frame 23:22:40 mmocny: validation could require a network hop 23:22:54 mmocny: [reads from slide] 23:23:17 mmocny: one common thing, you click, await fetch, before updating events 23:23:48 mmocny: document loading, there's a moment in time where the page is loaded and painted but not ready to receive input yet 23:23:57 mmocny: we have blocking=render but we don't have blocking=interactions 23:24:20 mmocny: it is very recommended that sites server render content without requiring scripts to run, but this means early renderings are without event listeners on many sites 23:24:33 .. very common to wait for DOMContentLoaded which means whole body has finished 23:24:43 .. module scripts are implicitly after this 23:24:59 .. many developers report that early interactions seem to perform better, but it's doing nothing 23:25:28 .. some workarounds, inline JS in the HTML, have a wrapper to capture and replay listeners later 23:26:20 ... more recently, there's a clever use of forms where all actions are wrapped with a form. But when your page is loading if an event arrives we'll do the default thing and submit the form reloading the page. It would have been much faster to run the already loaded script 23:26:28 .. maybe we shoudl be delaying event dispatch 23:26:57 .. if your script that would register event listeners is ready maybe we should let it run and put it behind the event queue 23:27:14 ... similar question, what about hit testing? we should capture before the layout shift 23:27:38 .. 5. lazy listeners. There could be many targets on the page that are lazy in loading controllers or listeners 23:27:54 tbondwilkinson has joined #async-event-listeners 23:28:04 .. we complain we're shipping too much JS, we incentivize being ready for event dispatch. Many sites rely on event capture and replay 23:28:26 ... instead of creating a giant bundle, server render the page, get started preloading portions of page (at low priority) 23:28:37 ... then when user does interact, switch to priority loading for that listener 23:28:44 .. but you have to rely on event replaying 23:29:06 .. this can be complicated, but it also breaks a lot of UA default features, preventDefault, user activation, accessiblity, etc 23:29:15 .. Maybe addEventListener could support promises 23:29:32 .. possibly following service worker event.waitUntil pattern 23:29:38 .. nav api has event.intercept 23:29:47 .. view transitions returns a promise, waits until resolved 23:30:01 .. or what if onclick could have a URL or some pattern to know what to load 23:30:08 q? 23:30:12 q+ 23:31:04 domfarolino has joined #async-event-listeners 23:31:07 noamr: about waitUntilUrgent, is this mostly common in listeners that are the reason for the notification. e.g. click link that is navigating, and you yield in there? Or is it a more general problem? 23:31:16 bas: a save button could be the same thing 23:31:25 noamr: right, if you save there's a low chance you're navigating 23:31:30 bas: save and quit is common 23:31:39 noamh has joined #async-event-listeners 23:31:48 mmocny: I think it is general, unique thing is when you're interacting with event that navigates you could have blocked it 23:32:01 ack noamh 23:32:36 noamh: we started working on fetchLater for last minute fetching on unload. Maybe we need to think about this more hollistically instead of pushing more arbitrary code towards unload 23:32:53 s/noamh/noamr 23:33:37 mmocny: FYI fechLater is an API that can fetch even after unloading. The two features would work really well together. E.g. you want to stuff the fetch payload eagerly, so that it is queued. It's the second part of the equation 23:33:51 noamr: can the first part also be more general? 23:34:29 mmocny: I'm motivated to solve this as lack of passive event listeners is significantly impacting web perf 23:34:43 mmocny: and the hesitation to do so would be addressed, at least partially, by this 23:35:28 noamr: one thing comes to mind, if we had passive listeners, and there is a nav starting. The nav starting would be a sign to run the listeners, or some, or multiple levels e.g. i don't care if it gets dropped 23:35:45 noamr: something a bit more generic than last minute work for the scheduler 23:35:49 bas: concrete example 23:36:20 noamr: if you have an onclick that adds something to analytics. This click event won't affect input feedback in any way, doesn't need to be quick just needs to happen before unload. You also don't want to block navigation and make it slower 23:36:30 bas: Maybe i misunderstood, but idleUntilUrgent also doesn't block 23:36:43 noamr: right, you don't want it to block, but it should block commit 23:37:06 mmocny: my undersatnding is we unload the doc but allow event loop to continue 23:37:31 mmocny: there are certain features that stop working but not all. I don't know if you have to delay this or not, but right now page freezes and you continue to do things 23:37:37 bas: wouldn't stuff stop working? 23:38:04 mmocny: in my experimentation, we'll commit the nav, show the new doc, but in the background there's some amount of time to schedule tasks. 23:38:13 bas: but those tasks might expect stuff to be around, like document 23:38:52 noamh: how critical is it to have reliably running events low priority? 23:39:11 mmocny: i believe the priority is distinct from desire to run before unload 23:39:22 mmocny: when dev says it's okay to run on idle, it means user is not waiting 23:39:33 bas: i agree, can we move away from idleBeforeUrgent which implies priority 23:39:39 bas: run before unload is more obvious to me 23:39:55 mmocny: maybe it's priority: eventually or priority: background *and* run before unload 23:40:02 bas: that makes more sense to me 23:40:20 mmocny: we could consider whether all tasks should be flushed. We could make it easier but we could choose to be more efficient 23:41:20 noamh: i still want to challenge assumption. Do we really want to encourage building something that assumes tasks will block navigation or might run while nav is happening? It seems like the wrong guidance 23:41:39 noamh: but ... there's no alternative for users, e.g. say they want to do a critical activity 23:41:46 bas: save the doc? 23:41:55 noamh: but that should be part of building a reliable application 23:42:19 noamh: you might want a more persistent way of doing things, not necessarily execute JS but have some ?? you can store 23:42:34 noamh: we can never guarantee 23:42:36 bas: there's never a guarantee anyways 23:42:49 noamh: exactly, developer needs to consider this 23:42:54 bas: right, but the probability is very different 23:43:27 bas: you develop your app on the assumption it won't crash, so you don't have to auto-save often, and good probability you don't lose stuff. If we can increase the odds that we can run before unload it helps 23:43:48 dom: I'm all for using priority based vocab to refer to increasing the probability that your work will run 23:43:59 dom: i'm not sure about unload. I'm worried we'll push lots of work towards unload 23:44:11 dom: I'm worried we'll have apps be fast until they unload 23:44:34 dom: I think we should talk about it in terms of priority. At what point in time can you tell the platform it is urgent to do your work rather than assuming the last point in time 23:44:43 bas: like an idle timeout? 23:45:22 mmocny: these are all great points. There's an implicit deadline that when you run code that blocks the user interaction there's an implicit frustration. We're moving this to the background 23:45:47 mmocny: I understand the concern, it is about signaling some assurance / making the patterns easier. The alternatives are yield and hope for best, but folks choose not to do this today 23:46:02 mmocny: alternately you can guarantee it runs and reduce perf, and folks choose to do this 23:46:08 mmocny: they are incentivized to do the bad thing 23:46:24 bas: I'd like to understand concern, what if we accumulate huge amount of things, why would that happen? 23:46:47 dom: probably lots of tasks would happen, but more would accumulate right before unload than would today 23:47:29 Scott: we are encouraging putting things in pagehide, but yes does making it easier become dangerous? 23:47:56 mmocny: maybe unload is wrong, e.g. resource contention, time limit may not be enough. Maybe this is high priority work. It's not supposed to block the interaction, but maybe it's eagerly flushed 23:48:28 noamr: I see this work as after input feedback before navigation response. It doesn't have to block nav start, etc 23:48:35 bas: there's multiple use cases 23:48:46 * everyone agrees lower than feedback 23:49:20 ??: i've looked at numbers, the unload event typically fires around the same as response time. we're not blocking navigation start 23:49:36 mmocny: right, you can do this already 23:50:20 philip: another scary situation, when doc starts unloading before it completes loading. We want to collect information. Do we want to make sure the nav still gets blocked? 23:50:49 mmocny: I see some folks deploying large apps in room, which are serious problems as opposed to problems that you've solved and are fine 23:51:14 mmocny: personally, I see it all the time 23:51:31 bas: is it possible frameworks frequently hide this from people? 23:51:31 mmocny: how? 23:51:31 bas: don't know 23:51:52 mmocny: stories i've heard is an ecommerce site invested in SSR, but it takes seconds for page to be interactive. 23:52:14 mmocny: this can be busy loading script, or browser is optimizing first render and hasn't attempted to load script yet, event is immediately handled as a no-op 23:52:21 q+ 23:52:28 mmocny: this might trigger default action, but it doesn't do anything 23:53:06 smaug: inert attribute, should you inert the html element? 23:53:15 bas: but it blocks the interaction, doesn't store it 23:53:21 smaug: but we can't replay it 23:53:29 .. layout is different 23:54:04 mmocny: my theory is this is already racy. When i interact, i send event to OS > browser > renderer > schedules, etc, it might not hit test for many frames, i hope there's no layout shift that changes target 23:54:19 mmocny: I still think we should find the visible target 23:54:38 mmocny: but we could do the same hit test we do today, capture the target immediately, but dispatch later 23:54:59 mmocny: you might have a normal priority task which would have added the event listener 23:55:08 smaug: of course you don't know the dependencies 23:55:16 bas: the author can indicate it in this case 23:55:37 smaug: the script might just be a tracking script. You just want to run the user input before the tracking script. It could be hard to figure out which scripts you want to load 23:55:43 mmocny: right, that's a risk 23:55:47 Ack noamr 23:55:50 Ack tbondwilkinson 23:55:51 q+ 23:56:39 (we're running quite a bit overtime) 23:56:50 tbondwilkinson: progressive hydration is pretty buggy. angular is working on it, others. That's one thing that may be interesting to focus on since frameworks are focusing on this. None of these seem like a complete dud. As a thought, how many frameworks use browser's event dispatch system? 23:56:56 .. probably not many, because it's not a great system 23:57:05 .. anything we can do to improve this would be great to encourage people to use the system 23:57:46 noamh has left #async-event-listeners 23:57:48 mmocny: thanks for discussion. I've linked to all of this from the session