The check for this.isLocal should take care of this, if you pass a correct value. It shouldn't be necessary to add more conditions. Is it not working?

I do apologize for not using jsFiddle. I am not familiar with jsFiddle, and since this is a local-only MSIE problem, I didn't think of that.

Now that I have done more thorough testing, I see that the problem is more complicated. All versions of jQuery - 1.10.2, 1.11.0, and 2.1.0 - fail in one way or another.

The test files are in http://chemapps.stolaf.edu/jmol/test, and you will have to download them and run them locally with MSIE 11 to see the problem.

There are four tests there. The first two are asynchronous, and the second two are synchronous. Tests 1 and 3 test remote access via AJAX from a local page; tests 2 and 4 test local access of local files.

I provide a working patched version of jQuery-1.11.0.

In summary:

Without the above patch,

jQuery 1.10.2 -- local-reading tests (2 and 4) fail in MSIE local

jQuery 1.11.0 -- remote-reading tests (1 and 3) fail in MSIE local

jQuery 2.1.0 -- local-reading tests (2 and 4) fail in MSIE local

It all has to do with MSIE still requiring the ActiveXObject, but only for local file reading of local pages. I think I have that right.

Let me know if you have any questions.

Bob Hanson

If you pass isLocal: true into each ajax request, does it work properly? If it does not I can look at the test cases.

All fail regardless of the setting of isLocal.

1.10.2 is still broken because it doesn't check for isLocal.

1.11.0 does not actually pass the user's isLocal setting to the method, so that still fails. I guess "this" isn't what you think it is. I don't see it, but it has something to do with ajaxSettings not being a function, and options.xhr() not being a prototype function.

2.1.0, as far as I can tell, doesn't even include ActiveXObject, and isLocal is never tested, so it fails.

Nothing we can do about older versions, so 1.10 is out of play.

I'll look at 1.11 to see what's going on. It should honor the isLocal if passed in.

Because 2.x doesn't use ActiveXObject and has been refactored to use XHR events which are not supported by ActiveXObject, you'd need to stay with the 1.x branch if you need to read local files.

Thank you for looking into 11.1. I would like to tell my users that they can provide that if they want to and are not forced to use my hacked version.

-- unsolicited comment follows --

As long as it is made clear to developers that jQuery 2.x does not support MSIE 11 fully, I suppose this is not an issue. Seems a bit extreme of a position to take to me, to simply not even consider the option of using ActiveXObject. I would think the reason for that was the ''belief'' that it was no longer necessary with MSIE 11, but clearly it is necessary, for whatever reason, so I suggest reconsidering that position and perhaps not being so hasty to jettison a piece that is still important in the latest release of a popular browser. It seems to me that the attempt to fix the problem with this.isLocal shows that people do care about this, though it was not implemented correctly and apparently not tested fully.

And the fix is so simple.

My 2 cents.

And the fix is so simple.

Awesome! you can file a pull request at http://github.com/jquery/jquery.

sorry - "pull request"? What is that? Are you saying this will be fixed? Or is fixed?

I misunderstood, it sounded like you had a simple fix and I was suggesting you submit it as a patch.

I gave you the simple fix in the first message. My whole point was to give you that and hope it could be implemented.

Here is is again:

return (!this.isLocal || this.url == document.location || this.url.indexOf("http") == 0) &&

instead of:

return !this.isLocal &&

The ticket is open, per http://bugs.jquery.com/ticket/14876#comment:5

My point there was that jQuery 2.x wouldn't get a fix because it would require a redesign to do that.

Without analyzing and doing a run against unit tests on supported browsers, I don't know whether that code snippet will fix the problem.

Exactly. And I consider it a hack. I've done what I can do -- provide simple cases in point, provided a work-around that works for me, suggested a reason why it the current code is bound to fail, and pointed out a design flaw in 2.1. The rest is yours.... I hope to see that whatever version is next fixes this problem, that although perhaps not common is still critical for some use cases.

As I said, I have my work-around. I do not like having to tell my users they cannot use their own version of jQuery and must use mine. So I honestly do hope you can find an appropriate fix. jQuery is great; I'm a big fan. But I'm not a jQuery developer. Just a knowledgeable user.

Bob Hanson

@hansonr I am looking at your test case http://chemapps.stolaf.edu/jmol/test/testMSIE-1.11.0.htm and do not see any where you explicitly pass in isLocal: true to $.ajax. Can you update your test case and let me know the result?

I think you misunderstand the test case. There is no significance in running it at my site. You have to download the HTML file yourself and run it locally, or there is no test. The problem is only when the page is on a local machine and the user is viewing it in MSIE.

So what you need to do in this case is download that test file, add whatever tests you want, such as isLocal:true, and run it yourself.

If I edit the file, it will be my test case and not yours. I prefer to have a real-code test case that you have verified does not work as you expect, rather than trying to create one via a wordy description. Does that make sense?

Feel free to own it. You have to download the file; you might as well edit it as well. It's an odd situation, where you can't test it your typical way; probably why it was isLocal was implemented improperly in the first place.

Or, just use any file with jQuery and MSIE and do an alert(this.isLocal) in the xhr-setting code for ajaxSettings.xhr. You will immediately see that "this" is not what you think it is, and "this.isLocal" has nothing to do with editing the HTML file we are talking about.

I'm sure you can figure this out. But it something odd about the way that ajaxSettings.xhr is defined.

Good luck!

Replying to [comment:13 hansonr@…]:

I've done what I can do -- provide simple cases in point, provided a work-around that works for me, suggested a reason why it the current code is bound to fail, and pointed out a design flaw in 2.1.

By not allowing local AJAX via the native XMLHttpRequest object, Microsoft showed clearly they don't want this functionality in IE; it remains supported via the ActiveX interface which should be avoided if possible.

There is no design flaw in 2.1 around XHR treatment. Making local AJAX possible in IE11 in jQuery 2.x would require to add *a lot code* handling the ActiveX case which would hurt all the jQuery users that don't need the feature.

Not a lot people need to do local AJAX in IE>8 and if you're one of them, feel free to continue using jQuery 1.x; it will live for a few more years. If you think this is not an acceptable solution long term, report the issue to Microsoft so that they allow local AJAX via the native XHR: https://connect.microsoft.com/ie/

Changing the milestone to reflect that only the 1.x line will get the fix.

Your test case doesn't really involve accessing local files but it works for me (unmodified from the way I downloaded it off your site) in IE11 on Windows 8.1. Here is a screen shot. For that reason I'm closing this as worksforme.

If you are still having issues, please work them out somewhere else such as StackOverflow and only report a bug if you have a clear test case that can be reproduced by several other people on other systems.