custom properties on dom events are discarded after microtask during event propagation
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
People
(Reporter: github, Unassigned)
Details
Attachments
(1 file)
|
3.95 KB,
text/html
|
Details |
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:141.0) Gecko/20100101 Firefox/141.0
Steps to reproduce:
Register two click event handlers. One on a container div, the other one on document.
Let the container click handler set a property on the event object (eg event.foo=5)
and then schedule a microtask (enqueMicrotask) that will take a few ms.
In the document click handler, check if the event.foo property is present.
In Svelte such a custom property on an event object is used to mark events as alsready processed while handling the event on multiple layers. (https://github.com/sveltejs/svelte/issues/16522).
Actual results:
Depending on the duraction of the microtask (that will run inbetween the two event handlers) the event.foo property will not always be visible to the outer (document) event handler. It seems as if the event object is garbage collected an recreated intween the microtask and the second event handler.
If the inner event handler stores the event object itself in some global variable or in a WeakMap or WeakSet, the foo property will always be visible to the outer event handler. So it seems keeping some reference to the event object prevents garbage collection.
Expected results:
From the perspective of the event handlers the event object should be treated as a single object that is consistent between all handlers - no matter if an additional reference to the event object is stored somewhere.
I would expect the foo property to always still be set when the event reaches the outer handler.
I know that many JavaScript libraries and frameworks attach custom properties to events so I would assume that a custom property not disapearing is crucial for many websites to work correctly. In Chromium based browers it works as expected.
Comment 1•8 months ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::DOM: Core & HTML' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
Comment 2•8 months ago
|
||
Suspiciously similar to bug 1980081.
Updated•7 months ago
|
Description
•