The issue appears to be CORS related since the error happens right after the CORS preflight request. I am not entirely sure why there would be CORS issues but do vaguely recall IE11 being a bit special when it comes to CORS.
The first thing I would check is whether IE identifies the site as part of the intranet zone and whether IE is falling back to an older version. Another thing to check is whether the users are accessing the site from a different origin i.e. protocol, hostname and port pair such as with a different DNS entry, including accessing the site via HTTP instead of HTTPS. Similarly, accessing things cross domain can be a potential issue and requires the appropriate headers on the server.
The range of possibilities are quite endless, but unfortunately none of the scenarios relate to the widgets or the extension so I fear the amount of support we can reasonably provide here is quite limited. I would suggest following up with Microsoft if possible.
Please let us know if there is anything else we can help with!
Thank you for the response, not sure if this is possible but one suggestion on sites I looked at is to supply headers.
Now, I’m not a developer per se but this could be the solution. Our IE setting is locked down so I’m pretty limited as to what I can do settings wise. However since Chrome is working I can work with the limitation of not using IE.
I found some links that maybe give some ideas on how to solve this programmatically.
Unfortunately most of the methods that those links cover would not be an option in this scenario. What intrigues me, however, is that cross-origin requests should not be coming into play here at all. These are requests to the same origin since the widgets are hosted by TFS and all requests should be going to the same host and will be using the same protocol, host and port pair. The question remains as to why these are being treated as cross-origin requests. We do not see the same behaviour with IE11 and TFS which makes me believe the issue is environmental.
IE11 can sometimes run in compatibility mode and things may be forced back to IE10 or earlier which also requires an additional P3P header to present when dealing with CORS headers. Things can also potentially fail when using self-signed certificates. Another potential explanation is the internet zones mentioned before.
We can’t do much about this exact problem and it doesn’t seem to make much sense to introduce CORS headers when these should be taken care of by the browser. There are numerous risks associated with getting it wrong and for not much gain. This isn’t to say that we won’t have a look at it, just that it’s pretty low on the priorities at the moment.
No problem, thank you again for your help. Since our environment is pretty restricted it will not be impossible that something in the our setting is preventing the widget to work.
I keep on forgetting to mention that our TFS is HTTPS while Octopus is using HTTP and we do use a self signed certificated (deployed by our IT security team).
No problem at all. I realize that what I suggested may not always be an option, but thought I would mention it regardless.
In regards to HTTPS vs HTTP; I think as long as the certificate is trusted and appears to be valid it should not be an issue, although there may be some caveats around that. The request to Octopus should be initiated by the server and not the browser, which shouldn’t cause any CORS issues as TFS is acting as a proxy. I had a look at the compatibility mode settings a bit more as well and widgets wouldn’t work at all if it was falling back to IE9 or earlier but seems to work fine with IE10. There is definitely something strange in your environment going on but can’t think of anything that may explain the exact behaviour.
I will try and dig into this a bit more when I get some free time, but feel free to let us know if there is anything else we can help with
