Re: [whatwg/dom] Proposal: asynchronous event listeners (Issue #1308)

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.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/1308#issuecomment-2364579265
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/dom/issues/1308/2364579265@github.com>