128

Like many others, my website is using jQuery. When I open the developer tools, I see a warning that says that XMLHTTPRequest is

deprecated because of its detrimental effects to the end user's experience.

I went on and read part of the documentation, but it was fairly technical. Can someone explain the consequences of shifting from XMLHTTPRequest to WHATWG in simple terms? It says it happened in 2012.

Also, the documentation says that Synchronous XMLHttpRequest outside of workers is in the process of being removed from the web platform, when that happens, if a user agent had them in a service, do they need to modify their existing code?

informatik01
  • 16,038
  • 10
  • 74
  • 104
Edd
  • 1,948
  • 4
  • 21
  • 29
  • 2
    You must be talking about synchronous XMLHTTPRequests, not asynchronous ones, correct? Synchronous requests are horrible for the end user experience (they lock up the browser during the request) and should generally not be used. – jfriend00 Jan 02 '15 at 00:54
  • 2
    provide some code that triggers this – charlietfl Jan 02 '15 at 00:56
  • I'm not writing any service code at this moment, my concern is: I want to learn to write code that doesn't require avoidable maintenance over time. I know I could work with ajax, but I haven't grasped the concept just yet. I used the jquery example for that reason. @charlietfl – Edd Jan 02 '15 at 01:05
  • 4
    Is this the full text in question? *Synchronous XMLHttpRequest on the main thread is deprecated because of its detrimental effects to the end user's experience.* – Qantas 94 Heavy Jan 02 '15 at 01:09
  • Specifications for different parts of browser APIs are sometimes moved around between different organisations -- this does not usually change anything for developers themselves. – Qantas 94 Heavy Jan 02 '15 at 01:12
  • 1
    jQuery only gives that warning for synchronous requests, doesn't it? Are you deliberately making a synchronous request? If so, the solution is to structure your code to work with asynchronous requests, which you should do anyway because they're much nicer from the user's point of view. – nnnnnn Jan 02 '15 at 01:23
  • 1
    I've seen that flag not only in my website, I've seen it some others, e.g. Youtube, as well. Regarding specifications, with what specification should my code be in compliance, W3C's or WHATWG's? , [reference](http://www.infoq.com/news/2014/10/w3c-ignores-whatwg) I don't want to ask in the main thread for it would be flagged as a matter of opinion I guess. @Qantas94Heavy – Edd Jan 02 '15 at 03:01
  • It is not jquery, it's chrome - http://src.chromium.org/viewvc/blink?view=revision&revision=184788 –  Feb 18 '15 at 12:11
  • please to edit the text of the flag to what Qantas pointed out. XMLHTTPRequest is not the subject of the issue, it is the synchrounous one on the main THREAD – Adib Aroui Oct 24 '15 at 12:19
  • 1
    Possible duplicate of [Javascript console.log causes error: "Synchronous XMLHttpRequest on the main thread is deprecated..."](http://stackoverflow.com/questions/24639335/javascript-console-log-causes-error-synchronous-xmlhttprequest-on-the-main-thr) – Stephan Weinhold Mar 24 '16 at 15:12

6 Answers6

145

To avoid this warning, do not use:

async: false

in any of your $.ajax() calls. This is the only feature of XMLHttpRequest that's deprecated.

The default is async: true, so if you never use this option at all, your code should be safe if the feature is ever really removed.

However, it probably won't be -- it may be removed from the standards, but I'll bet browsers will continue to support it for many years. So if you really need synchronous AJAX for some reason, you can use async: false and just ignore the warnings. But there are good reasons why synchronous AJAX is considered poor style, so you should probably try to find a way to avoid it. And the people who wrote Flash applications probably never thought it would go away, either, but it's in the process of being phased out now.

Notice that the Fetch API that's replacing XMLHttpRequest does not even offer a synchronous option.

Yann39
  • 14,285
  • 11
  • 56
  • 84
Barmar
  • 741,623
  • 53
  • 500
  • 612
  • 9
    This is jQuery's warning then. I can ignore it? I don't use synchronous calls to the server. The perfectionist side of me doesn't like having warnings at all. – Jordan Feb 20 '15 at 19:48
  • 2
    @Jordan I think the warning is coming from the browser, not jQuery. It will happen whenever you try to use synchronous AJAX. If you use jQuery, that will only happen if you specify that option to `$.ajax`. – Barmar Feb 20 '15 at 21:47
  • I am working with `jquery-2.1.4.min.js` and I have the same warning on Firefox, Chrome and Opera, and I am not using `$.ajax()`. When I do click in that warning it opens the `jquery-2.1.4.min.js` file of course. – Manuel Jordan Jan 04 '16 at 16:28
  • You must be using some other library that uses `$.ajax`. – Barmar Jan 04 '16 at 16:33
  • 2
    I am using `jquery.i18n.properties.js` but there is no an explicit call by my side to `$.ajax.` Perhaps internally, but not sure. – Manuel Jordan Jan 04 '16 at 19:02
  • Something must be calling $.ajax with that option. Or maybe there's a call to `$.ajaxSetup` that sets it as the default. But the warning message doesn't happen for no reason. – Barmar Jan 04 '16 at 19:09
  • 1
    That plugin loads resource bundles from `.properties` files. It's probably using synchronous AJAX to do it, causing this warning. – Barmar Jan 04 '16 at 19:23
  • Look on line 74 of https://github.com/jquery-i18n-properties/jquery-i18n-properties/blob/master/jquery.i18n.properties.js – Barmar Jan 04 '16 at 19:24
  • Good catch @Barmar I am going to report it on its page how an issue. Thanks! – Manuel Jordan Jan 05 '16 at 01:36
  • Mine must have something to do with $('.modal').on('shown.bs.modal', function (e) { $(remote_target).load(remote); }); – yardpenalty.com Sep 01 '16 at 14:15
  • @ManuelJordan I had the same warning, you can call $.i18n.properties with async: true parameter $.i18n.properties({ async: true, name: 'messages', ....... }); (maybe you have solved, but for the others... ) – Paolo Biavati Oct 25 '16 at 17:20
  • @Barmar i ahve tried with giving async value as true, but still it is showing me the same error is there any other thing which i have missed – Meena Aug 04 '17 at 10:13
  • @Meena Are you sure the warning is coming from your AJAX call, not a third-party library you're using? – Barmar Aug 04 '17 at 17:43
  • 1
    @ManuelJordan setting async: true in i18n can cause a delay in showing the strings displayed in your page on slow connection. Showin instead the string code – Siyon DP Dec 28 '17 at 09:18
  • @TSion.D.P If the connection is slow, you'll have a delay either way. Synchronous AJAX will block the browser while waiting for the request to complete. – Barmar Dec 28 '17 at 16:54
  • I need to using that feature for onetime token, does it have any other solution? – nobjta_9x_tq Nov 29 '18 at 04:09
  • @nobjta_9x_tq You should write proper asynchronous code that uses the token in a callback. See https://stackoverflow.com/questions/14220321/how-to-return-the-response-from-an-asynchronous-call – Barmar Nov 29 '18 at 12:52
  • This warning still appears even when the `async` option is not explicitly used because jQuery still sends a boolean representative to XMLHttpRequest.open(), defaulted to `true`. I've come to the conclusion that this is not an issue as I never explicitly set `async`, and the notice will stop occurring once the `async` option is removed from jQuery. – Aufgeschissener Kunde Jan 11 '19 at 17:34
  • 1
    @AufgeschissenerKunde The issue isn't whether the async option is used explicitly or not. The warning only appears when you request synchronous AJAX. I never see the warning from my `$.ajax` calls. – Barmar Jan 11 '19 at 19:31
  • This totally avoids an obvious question of what if a person wants synchronous – barlop Jul 10 '19 at 18:36
  • @Barmar yeah `async :true` is fine and this doesn't answer what if he wants sync – barlop Jul 10 '19 at 18:37
  • @barlop Then they're in danger of their code not working if and when synchronous AJAX is actually removed from browsers. The deprecation message is a warning that this might happen in the future. – Barmar Jul 10 '19 at 18:37
  • If you actually want it, code it and ignore the messages. The user never sees them unless they open the console. – Barmar Jul 10 '19 at 18:38
  • @barlop I've updated my answer to address your question some more. – Barmar Jul 10 '19 at 19:33
  • I am seeing this when doing $.get(), should not that be async by default? – Giulio Aug 18 '20 at 08:47
  • 1
    @Giulio Yes, unless you've used `$.ajaxSetup()` to change the default. – Barmar Aug 18 '20 at 14:27
  • @Barmar No, I did not use `$.ajaxSetup()` at all, but the warning is there. – Giulio Aug 19 '20 at 10:03
  • 1
    @Giulio Something in your code must be overriding the jQuery default. I can't think of any reason. – Barmar Aug 19 '20 at 13:53
  • Anybody else: turn on LogXMLHttpRequests in Console. It showed me that inside the page that I was correclty loading with an async get there was a ` – Giulio Aug 24 '20 at 12:38
63

The accepted answer is correct, but I found another cause if you're developing under ASP.NET with Visual Studio 2013 or higher and are sure you didn't make any synchronous ajax requests or define any scripts in the wrong place.

The solution is to disable the "Browser Link" feature by unchecking "Enable Browser Link" in the VS toolbar dropdown indicated by the little refresh icon pointing clockwise. As soon as you do this and reload the page, the warnings should stop!

Disable Browser Link

This should only happen while debugging locally, but it's still nice to know the cause of the warnings.

Sam
  • 4,994
  • 4
  • 30
  • 37
  • One can disable in `web.config` by adding `` inside `` as described here: http://www.poconosystems.com/software-development/how-to-disable-browser-link-in-visual-studio-2013/. – Beel Dec 04 '16 at 18:30
  • 3
    I think this is a bad suggestion just to get ride of warning messages in the console. Disable browserlink and get rid of the productivity enhancements that browserlink adds just so you won't see a warning message in the browser console? Better to file a bug with microsoft and it gets fixed. – coding4fun Dec 09 '16 at 20:36
  • 4
    @coding4fun Thanks for your opinion; you can feel free to file a bug with Microsoft. I wasn't saying you should disable Browser Link. My answer is accurate as to the cause of this warning in some cases and it's useful to rule out something in your own code. I personally felt better once I realized it wasn't something I did wrong and thought others might find it helpful as well. – Sam Dec 12 '16 at 15:01
  • This fixed more than just the ajax warning. I got all kinds of browser link mess in the javascript console using asp core. – JoeBass Apr 15 '17 at 22:50
  • Would anyone know what is browser link and why does it end end up giving such a warning? – gideon Jun 07 '17 at 13:44
  • Browser link is useful because it inserts a script into your page during debugging, which allows communication between the page with Visual Studio, using Javascript and SignalR. So if you change a certain HTML file, content will be updated in the page automatically. Changing a CSS file will also make style changes immediately visible in the browser without the need to refresh it. So if the only thing that bothers you is the warning, you don't need to disable it. – vgru Jun 26 '17 at 09:16
  • Did anyone ever file a bug report for this at MS? I looked at https://developercommunity.visualstudio.com/ but maybe is one somewhere else? Otherwise I would create one. – bugybunny Dec 19 '18 at 15:55
  • Browser should provide backward compatibility to synchronous call. Because, there are lots of code which used synchronous call. I even notice that jqgrid4.1 is still using synchronous method. It is really horrible and discouraging if they really remove it from browser. – Mr. Aniket Jan 13 '19 at 18:27
  • Thank you so much @Sam. I fought with the Synchronous XMLHttpRequest issue for days until I found your solution. I disabled the browser link and the messages are gone. Now I just have to figure out why I can't get the .done(function()...) part to work. Thank you again. –  Jan 24 '20 at 21:40
17

This happened to me by having a link to external js outside the head just before the end of the body section. You know, one of these:

<script src="http://somesite.net/js/somefile.js">

It did not have anything to do with JQuery.

You would probably see the same doing something like this:

var script = $("<script></script>");
script.attr("src", basepath + "someotherfile.js");
$(document.body).append(script);

But I haven't tested that idea.

Dave Friend
  • 171
  • 1
  • 2
  • The warning went away for me when I removed a line like this, which I wasn't using anyway: @Html.Script("~/scripts/apps/appname.js") – MsTapp Jan 04 '16 at 16:22
11

It was mentioned as a comment by @henri-chan, but I think it deserves some more attention:

When you update the content of an element with new html using jQuery/javascript, and this new html contains <script> tags, those are executed synchronously and thus triggering this error. Same goes for stylesheets.

You know this is happening when you see (multiple) scripts or stylesheets being loaded as XHR in the console window. (firefox).

Hugo Delsing
  • 13,803
  • 5
  • 45
  • 72
2

No one of the previous answers (which all are correct) was suited to my situation: I don't use the async parameter in jQuery.ajax() and I don't include a script tag as part of the content that was being returned like:

<div> 
     SOME CONTENT HERE
</div>
<script src="/scripts/script.js"></script> 

My situation is that I am calling two AJAX requests consecutively with the aim to update two divs at the same time:

function f1() {
     $.ajax(...); // XMLHTTP request to url_1 and append result to div_1
}

function f2() {
     $.ajax(...); // XMLHTTP request to url_2 and append result to div_2
}

function anchor_f1(){
$('a.anchor1').click(function(){
     f1();
})
}

function anchor_f2(){
$('a.anchor2').click(function(){
     f2();
});
}

// the listener of anchor 3 the source of problem
function anchor_problem(){
$('a.anchor3').click(function(){
     f1();
     f2();
});
}

anchor_f1();
anchor_f2();
anchor_problem();

When I click on a.anchor3, it raises the warning flag.I resolved the issue by replacing f2 invoking by click() function:

function anchor_problem(){
$('a.anchor_problem').click(function(){
     f1();
     $('a.anchor_f2').click();
});
}
Mogsdad
  • 44,709
  • 21
  • 151
  • 275
Adib Aroui
  • 4,981
  • 5
  • 42
  • 94
  • 6
    Scripts are not executed if you directly insert them into the DOM via innerHTML. So when you call .html(), jQuery fetches and executes any scripts included in the html response synchronously. – Henry Oct 25 '15 at 07:10
  • @HenryChan, I tried to understand you but to no avail. Could you please explain to me in simpler words. I don't insert scripts into the DOM, I insert only HTML and still this solution is the only working solution for me. Thanks in advance – Adib Aroui Aug 05 '16 at 12:09
  • 3
    @whitelettersinblankpapers I think he means: inside your ajax callback, if the contents that you append to your "div"s contain script tags, then these will be called synchronously. – Haitham Sweilem Dec 07 '16 at 11:42
0

My workabout: I use asynchronous requests dumping the code to a buffer. I have a loop checking the buffer every second. When the dump has arrived to the buffer I execute the code. I also use a timeout. For the end user the page works as if synchronous requests would be used.

runback
  • 7
  • 3
  • do you have a little bit code for me to know how to achieve this? – ZerOne May 27 '15 at 08:07
  • 6
    @runback, can't the done() promise callback be used ? `$.ajax({ url : "example.com", async : true /* default is true */ }).done(function(response){ // Process the dump })` Hope I have not mis-read anything. – pravin May 30 '15 at 06:50