-
Notifications
You must be signed in to change notification settings - Fork 387
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
Leaky abstraction in the use of window.postMessage()? #410
Labels
Comments
This is a fair concern. However, a postMessage handler should always be only reacting to explicit message types, never broadly reacting to every event - so I'm not sure it's a real issue. I'll leave this open in case others have thoughts. |
One possibility is overriding |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi guys,
It looks like you're using window.postMessage("zero-timeout-message", ...) to implement an internal enqueue method. This bit me while running unit tests in PhantomJS. We have a message event listener registered on the window, and it's getting invoked with "zero-timeout-message", which causes it to break unless we explicitly filter your message type.
Does it make sense for your clients to have to guard against your message types? I'm not sure of convention in this case, but it smells odd, so I wanted to bring it to your attention.
Thank you!
The text was updated successfully, but these errors were encountered: