IE8 function createXhr(method) returns window.XMLHttpRequest(), is undefined #5677
Comments
ghost
assigned 
|
Most probably you are using quirks mode. You can double check by opening the IE Dev Tools. Please comment if that's not your problem... |
|
I checked that and it's not the problem. Edit: I actually ran it in quirks mode, but Angular warns about that apparently. Those logs do not show up normally. |
|
It's my company's anal security policy. Closed indeed... It does mean you can still check for the existence of window.XMLHttpRequest before you return it, which is a more sturdy way of checking it than just going by browser version. |
|
Actually this doesn't seem unreasonable --- the updated createXHR stuff threw away a lot of stuff, and we might not be throwing the noxhr minerr anymore, or at least not under the same circumstances. I'm not totally sure, but it's possible that this could be improved |
|
As long as my companies policies do not change, I'll roll my own: function createXhr(method) {
// IE8 doesn't support PATCH method, but the ActiveX object does
/* global ActiveXObject */
return ((msie <= 8 || lowercase(method) === 'patch')|| isUndefined(window.XMLHttpRequest))
? new ActiveXObject('Microsoft.XMLHTTP')
: new window.XMLHttpRequest();
} |
|
@jorgt that particular code is going to instantiate an ActiveXObject regardless of the browser if the method is PATCH... That's not totally good. But if you can improve this and turn it into a pull request which doesn't hurt evergreen browsers, it should be totally mergeable. Once we have some better E2E test infrastructure, we can totally do a much better job of testing this stuff to make sure it actually works correctly. |
As per this issue: angular#5677 window.XMLHttpRequest is not always available in IE8 despite it not running in quirks mode, in which case Angular should be using the ActiveXObject instead. Just checking the browser version is taking too many shortcuts.
|
My first pull requests, I hope that's ok. Thanks for catching the erroneous "||" I tried before. |
|
@caitp I don't think that we'll ever have test for various IE security policy variations ;-) (just setting the expectations) |
|
@IgorMinar what I meant was that we can be a bit more confident that changes to the httpBackend (for example) won't break evergreen browsers, or support IE browsers with "conventional" configurations, without testing manually. I think that is definitely something doable |
As per this issue: angular#5677
window.XMLHttpRequest is not always available in IE8 despite it not running in quirks mode, in which case Angular should be using the ActiveXObject instead. Just checking the browser version is taking too many shortcuts. Closes angular#5677 Closes angular#5679
in IE8 on GET (and other) requests this returns a
new window.XMLHttpRequest()which at least in my case throws a "typeerror: object expected" exception. Shouldn't this always return the ActiveXObject where < IE8 is concerned?The text was updated successfully, but these errors were encountered: