Closed jvincilione closed 8 years ago
Have you had a chance to take a look yet?
How is the ajax code related to whether waitForReady fires or not? If you're referring to using easyXDM's RPC feature to proxy ajax calls across the domain barrier (by the way, in Edge you should just use straight up CORS), then I suggest you start with a smaller test that simply renders a regular easyXDM iframe.
Without a broken down test, it's not really possible to say where this issue lies.
This bug also contain no reference to actual code related to easyXDM.
This bug references the waitForReady function that is a callback for the window "message" event. (First sentence in post.) Aside from that, I'm showing my implementation.
I originally thought it was an ajax issue, which is why I didn't post it on here until after I put a bounty on the question on stack, because that's when I narrowed it down to the waitForReady function in easyXDM. The function is in PostMessageTransport.onDOMReady
.
Just to clarify, we've been using easyXDM for quite a while. (~3 years I'd guess. It was in use before I started with the company 2 years ago.) With that being said, the implementation we've been using has worked that entire time until Microsoft Edge launched, and it doesn't work in edge.
What we've found when stepping through, is that the event listener is created, and then later triggered using callerWindow.postMessage(config.channel + "-ready", targetOrigin);
Even though the event is triggered, nothing happens. (The callback function is never called/run, verified via console.log() and using breakpoints).
Regarding using "straight up CORS", I'm not sure if that is feasible. We're using easyXDM inside of an iFrame on other websites. We run all of our ajax requests through the RPC proxy. Once again, there is no issue on Firefox, Safari, Chrome or IE 9+ (we don't support below 9), the issue is only in Edge.
Here is the onDOMReady method for your reference:
onDOMReady: function(){
targetOrigin = getLocation(config.remote);
if (config.isHost) {
// add the event handler for listening
var waitForReady = function(event){
//******** this function never runs ***********
if (event.data == config.channel + "-ready") {
// replace the eventlistener
callerWindow = ("postMessage" in frame.contentWindow) ? frame.contentWindow : frame.contentWindow.document;
un(window, "message", waitForReady);
on(window, "message", _window_onMessage);
setTimeout(function(){
pub.up.callback(true);
}, 0);
}
};
on(window, "message", waitForReady); <---- this runs
// set up the iframe
apply(config.props, {
src: appendQueryParameters(config.remote, {
xdm_e: getLocation(location.href),
xdm_c: config.channel,
xdm_p: 1 // 1 = PostMessage
}),
name: IFRAME_PREFIX + config.channel + "_provider"
});
frame = createFrame(config);
}
else {
// ************* this block runs after the above block ***********
// add the event handler for listening
on(window, "message", _window_onMessage);
callerWindow = ("postMessage" in window.parent) ? window.parent : window.parent.document;
callerWindow.postMessage(config.channel + "-ready", targetOrigin);
setTimeout(function(){
pub.up.callback(true);
}, 0);
}
}
Thanks for looking into this, but it turns out there was a required "hack" that a previous developer wrote into our implementation of easyXDM.
In our implementation of easyXDM, we had to update the Window
object on IE because our app launches in an iFrame. As Edge isn't technically a version of IE, our test was failing, so the code was not running to update window
to be window.parent
in the context of easyXDM.
We are using typeof document.documentMode === 'number'
to detect IE, but document.documentMode
is undefined in Edge, so we added a navigator.userAgent
check for Edge.
This resolved the issue.
Sorry for wasting your time.
waitForReady() is not firing on(window, "message", waitForReady) in edge. I'm looking into the issue more now.
I've stepped through in Chrome for Windows and Mac along with Microsoft Edge, and can find no difference in the data being passed or methods being called. The only thing that is different is waitForReady actually get's called and fires off a series of methods that actually send the message.
In Microsoft Edge, a GET request is not running. I have stepped through the code to the point of the AJAX request being run, and set a breakpoint in the callback(s). However, the code never reaches the callbacks.
I already have a .then() and .fail() setup with callbacks, and tried adding a .done() and .always() with callbacks, but none of the code in the callbacks is running.
I then checked the network tab in dev-tools, and I cannot find the request at all. It seems as though Edge is not firing the request off for some reason.
This is what calls the request function above.
This is the implementation used to make that request.
Here is the cors stuff. (I don't know a whole lot about this.)
Here is the related Stack Overflow question. I've put a 100 rep bounty on it if someone can figure it out.
http://stackoverflow.com/questions/34442460/microsoft-edge-easyxdm-onmessage-event-not-being-called