This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
This is a HORRIBLE change! Do you realize how many sites rely on async = false?? This is a necessary thing to use when you don't want the user to be triggering other scripts (i.e. by clicking on a screen button) while waiting for a response. You guys seriously need to rethink deprecating this! Best practices aside, it should be up to the developer whether or not to piss off users by freezing the screen until code is executed. Developers will still do this, the only difference is that it's going to be a pain in the ass to accomplish what is now very easy to do by using async = false. PLEASE RECONSIDER! http://xhr.spec.whatwg.org/#sync-warning [[ Developers must not pass false for the async argument when the JavaScript global environment is a document environment as it has detrimental effects to the end user's experience. User agents are strongly encouraged to warn about such usage in developer tools and may experiment with throwing an "InvalidAccessError" exception when it occurs so the feature can eventually be removed from the platform. ]]
You're very confused. This change doesn't stop developers from using sync XHR or remove the feature, it just says not to do it and encourages browsers to display console warnings to let developers know they're doing something bad. Inexperienced developers who think that they should use sync XHR to keep users from interacting with the page is exactly the sort of reason sync XHR needs to go away.
*** This bug has been marked as a duplicate of bug 24789 ***
This is on the console of the newest development version of Firefox (Nightly): "Synchronous XMLHttpRequest on the main thread is deprecated because of its detrimental effects to the end user's experience. For more help http://xhr.spec.whatwg.org/" I'm not confused, but maybe the Firefox developers are? Using Sync XHR is similar to clicking on a link to go to another page or submitting a form, except that the site doesn't have to refresh and reload everything. Why would this be used only by the inexperienced programmer? For example, a login script or a save to the server before the user loses the displayed information. It would be a pain to tell all other scripts to not respond while processing this script, or to place a huge box over the interface (which wouldn't prevent the nefarious users from making their own javascript calls via the url bar). Sometimes there is GOOD reason to lock an interface until a process either confirms or rejects a server call. There are other instances where we would need a sync call too, like triggering a script before telling a video or audio file to play. Loading an HTML5 media file on a mobile device generally requires the user to actually click on a button that then triggers the .play() or .load() function, and if you use an ASYNC call for this, the media file simply won't load.
*** Bug 24789 has been marked as a duplicate of this bug. ***
Indeed. Developers will need to do more work to the user's benefit. Users trump developers.
Hi there.. wrt Chris' original comment - I was unaware of it (till now, when I came across it), and had posted a nearly identical one here: https://bugzilla.mozilla.org/show_bug.cgi?id=969671 So, OK, good to know developers can still use async=false "if they want". Given that, the word 'deprecated' does not make sense, and confuses developers who will think that sync loading is going to be removed at some point in the future. Saty
They can use it at their own risk. There's no guaranteed stability for that API and therefore it is marked deprecated and forbidden to be used.