Leaky abstraction in the use of window.postMessage()?

[istarnx]

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!

[ljharb]

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.

[ljharb]

One possibility is overriding addEventListener to filter out our postMessage events, but that seems like it'd introduce a lot of latency for users for minimal gain :-/