why does jsf.js use a synchronous req here

[Cedric Bosch]

While checking the console on ajax req I was surprised that I had that warning message in the dev tool console:

Synchronous XMLHttpRequest on the main thread is deprecated because of its detrimental effects to the end user's experience. For more help, check https://xhr.spec.whatwg.org/.

After investigation it seems like this is the cause of this :

 /**
* Load a script via a url, use synchronous XHR request. This is liable to be slow,
* but it's probably the only correct way.
* @param url the url to load
* @ignore
*/
var loadScript = function loadScript(url) {
var xhr = getTransport(null);
if (xhr === null) {
return "";
}
xhr.open("GET", url, false);
xhr.setRequestHeader("Content-Type", "application/x-javascript");
xhr.send(null);
// PENDING graceful error handling
if (xhr.readyState == 4 && xhr.status == 200) {
return xhr.responseText;
}
return "";
};

Why is it probably the only correct way ?? And when is this used ?

source : http://grepcode.com/file/repo1.maven.org/maven2/com.sun.faces/jsf-impl/2.2.12/META-INF/resources/javax.faces/jsf-uncompressed.js?av=f

[Tim Holloway]

Actually, on casual reading of that code I'm not sure that it is a synchronous request. The comments could possibly be out of date.

There are 2 reasons why synchronous requests might be justified:

1. On the server side. If the request isn't idempotent, then having other requests serviced at the same time could scramble the results.

2. On the client side. If the xhs manager gets confused as to which received response it gets matches which request. Since web servers handle requests asynchronously (and often in parallel), it's possible for request A to precede request B, but get back request B's response before you got back the response for request A.