MS Edge compatibility issue with processQueue()
See original GitHub issueThis is a little hard to reproduce, and I think there is an issue with how Edge handles iframes. We have no problem with this same app in Chrome or Safari or Firefox.
What I have observed is that when my app loads for the first time, in a fresh tab (disabling the cache in the devtools doesn’t work, this needs to be a fresh tab), the first event object that is passed into processQueue results in the boolean event.source === global returning false.
I have seen this false value come from two different causes:
-
The event is a “load” event and not a “message” event. In the course of my debugging, I only saw this a couple of times, so I think there may be a race condition in the way the processQueue function is called.
-
Much more common, what I observed is that when the page loaded, the event.source was the “main” window, and global was the iframe window object. I don’t know what it is about how my app loads that causes the window objects to be different sometimes, and the same other times. This code seems to be hit three times during load, and only the first time are the window objects different.
Something about the false value is causing the rest of my app not to work, possibly because the queue never gets flushed?
If I change the code so that flushQueue() is called outside the if statement, then things seem to work ok (I am just beginning browser testing with Edge, so it’s possible I’ll find other issues).
processQueue = (function () {
return hasPostMessage
? function processQueue (event) {
if (event.source === global && event.data === messageName) {
event.stopPropagation();
}
flushQueue(); // THIS IS THE LINE I MOVED
}
: flushQueue;
})()
I am reluctant to submit this as a Pull Request, because I’m not sure if there are any negative consequences to making this change. I’d appreciate it if you/someone could review this.
Issue Analytics
- State:
- Created 5 years ago
- Comments:6 (2 by maintainers)
Top GitHub Comments
@arqex That seems to have done the trick for the case we were seeing. Thanks for the quick turnaround here!
I have just published a new version that it’s not using
event.source
anymore to check what’s the origin of the message. Let me know if it fixed your issue.