Consider to add signal to addEventListener
Categories
(Core :: DOM: Events, task)
Tracking
()
Tracking | Status | |
---|---|---|
firefox86 | --- | fixed |
People
(Reporter: smaug, Assigned: smaug)
Details
(Keywords: dev-doc-complete)
Attachments
(1 file)
Assignee | ||
Comment 1•3 years ago
|
||
This passes the tests which are in https://github.com/web-platform-tests/wpt/pull/26472
Because of complications in #include handling, AbortFollower needs to be in a different
header file than AbortSignal, yet AbortSignalImpl needs to be available when AbortFollower is used.
Another option would have been to make DOMEventTargetHelper.h a bit different and uninline some hot methods
there or move them to another file, but that would have been equally bad and Abort* is used way less often.
AbortFollower and AbortSignalImpl are thus just moved to a new header.
Memory management is such that Listener in EventListenerManager owns the possible ListenerSignalFollower
instance which follows the relevant signal. In order to be able remove event listener,
ListenerSignalFollower has many similar fields as Listener.
ListenerSignalFollower can't easily have just a pointer to Listener* since Listener isn't stored as a pointer
in EventListenerManager.
ListenerSignalFollower cycle collectable so that Listener->ListenerSignalFollower can be traversed/unlinked
and also strong pointers in ListenerSignalFollower itself can be traversed/unlinked.
There is an XXX in the .webidl, since nullability of signal is unclear in the spec pr.
Whether or not it ends up being nullable shouldn't change the actual C++ implementation.
Updated•3 years ago
|
Pushed by opettay@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/b3d0fba5fd8d Consider to add signal to addEventListener, r=edgar
Comment 3•3 years ago
|
||
bugherder |
Comment 4•2 years ago
|
||
The only information docs needed for this is BCD, which I am taking care of on https://github.com/mdn/browser-compat-data/pull/9562.
Updated•2 years ago
|
Description
•