-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
We should forward the subscribers abort signal to eventListeners #187
Conversation
cc @domfarolino |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! This is a great catch.
6a737d2
to
c81de62
Compare
Thank you so much for your review here @domfarolino, I have addressed the points. You're so good at this spec stuff. Learning a bunch. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks a lot for the contribution!
c81de62
to
391600b
Compare
@domfarolino I have rebased from the current master. Let's hope that fixes the CI. |
SHA: 5df4a38 Reason: push, by domfarolino Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
I think there is a possible event listener leak that can occur if we don't have a mechanism to clean up event listeners as subscriptions are aborted.
In WebKit I confirmed, that if we were to follow the spec we'd keep listeners around for a little too long:
Much like Chrome's EventTarget implementation, WebKits' also immediately take ownership of the EventListener, so that despite the Observable is marked for GC (
active == 0
), the listener hangs around.and I think Chrome had a similar discovery, as they also forward the signal to the event listener to trigger the abort steps.
Preview | Diff