Steps to reproduce
This is a tricky one because it does not always reproduce. You may have to attempt on multiple machines/virtual machine and try multiple repro cases to get it, but once you do, it is deterministic:
Use Microsoft Edge 38.x/EdgeHTML 14.x
(on my test machine, I have Microsoft Edge 38.14393.0.0 with EdgeHTML 14.14393).
Add the crossorigin attribute to the script tag. In my repro case, I use crossorigin="anonymous". As of now, in theory, Edge does not support this attribute and it should have no effect…but it does.
Load the webpage in Edge 14.x (previous version of Edge did NOT have this bug).
Sometimes, (and in a deterministic fashion, the script tag will be loaded (either downloaded or from cache), but it will not execute.
The key to reproduce is:
- html document is on one domain
- script tag is on a different domain
- crossorigin="anonymous" is present
- EdgeHTML 14.x
if any of those criteria do not apply, you will not be able to reproduce the bug.
To make it worse: if you reproduce the bug, and then clear the cache or modify the script in a way that will cause the browser to retry, it may “fix” the problem (at least temporarily. In my case, clearing my browser’s cache fixed the problem for a while, and then it started happening again).
To make it even harder to diagnose, if you successfully reproduce the bug, and keep refreshing the page, opening the debugger, etc, eventually the issue will stop happening, requiring restoring our virtual machine from a snapshot to be able to reproduce again.
Example of pages where the issue occurs:
If everything works, you will see
true logged to the console. If it fails, you will see
'success' is undefined
The above 2 pages are exactly the same and point to the same scripts, but as of this writing, Edge fails on 1) but not on 2). Removing the
crossorigin attribute on the script fixes it. On some machines, you will see the other way around (fails on 2) but not on 1). It may even fail on both. We haven’t been able to pin point the exact reason for the inconsistencies.
What we do know is that it is impacting a large portion of our Edge user base, and that removing the
crossorigin=anonymous attribute fixes it (but causes other problems in modern browsers, such as missing stack traces on error, so it is not an option to remove).
Comments and activity
- Microsoft Edge Team
Changed Assigned To to “Brad E.”
This has just been reported by a client. As you say, not easy to reproduce (I couldn’t). So just for the few Edge users they have, we’ve had to change
And modify the security policy.
It affects some machines and not others in the same office with the same Windows and Edge versions.
The editor removed my code samples so trying again.
1st one was “”
2nd one was “”
The code samples displayed correctly in the “Preview” pane, so I suggest there’s something up with this interface! Sometimes wonder why I bother with MS at all.
- Microsoft Edge Team
Changed Assigned To to “Travis L.”
Changed Assigned To from “Travis L.” to “Jeff W.”
Changed Status to “Confirmed”
We’re seeing this on an application that uses iframes. We load angular.js in both the parent page and in a frame. The parent page has the crossorigin=anonymous attribute set (as well as the integrity attribute), but the request generated does not include an Origin header. Then an iframe is loaded which also loads angular from the same URL and the crossorigin attribute (and integrity attribute). This request does include an Origin header and also an If-Modified-Since header. The server (AWS cloudfront) responds with a 304 and then nothing happens. Angular does not execute inside the iframe at all and generates no errors either.
So, I’ve been testing it on the creator update a couple of times while it was in preview, and yesterday via the “real” release, and it SEEMS to be fixed? Since it was not completely deterministic I’m not 100% sure, but I’m optimistic.