Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Bug 1679204 - Consider to add signal to addEventListener, r=edgar
This passes the tests which are in web-platform-tests/wpt#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 is 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. Differential Revision: https://phabricator.services.mozilla.com/D97938 UltraBlame original commit: b3d0fba5fd8d624b5abf53df196aedae5e83a269
- Loading branch information