969671 - Warn about use of sync XHR in the main thread

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Olli Pettay [:smaug][[e-mail]]]

http://xhr.spec.whatwg.org/#sync-warning

We should warn at least when it is used outside various unload event listeners.

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

Attachment: something like this

this should warn when we're not handling pagehide/beforeunload/unload listeners.

Comment 2

[(no longer active)]

Comment on attachment 8372677 [details] [diff] [review]
something like this

Review of attachment 8372677 [details] [diff] [review]:
-----------------------------------------------------------------

::: content/base/src/nsXMLHttpRequest.h
@@ +747,5 @@
> +
> +  static bool sDontWarnAboutSyncXHR;
> +};
> +
> +class AutoDontWarnAboutSyncXHR

Please annotate with MOZ_STACK_CLASS.

::: dom/locales/en-US/chrome/dom/dom.properties
@@ +144,5 @@
>  ShowModalDialogWarning=Use of window.showModalDialog() is deprecated. Use window.open() instead. For more help https://developer.mozilla.org/en-US/docs/Web/API/Window.open
>  # LOCALIZATION NOTE: Do not translate "window._content" or "window.content"
>  Window_ContentWarning=window._content is deprecated.  Please use window.content instead.
> +# LOCALIZATION NOTE: Do not translate "XMLHttpRequest"
> +SyncXMLHttpRequestWarning=Please don't use synchronous XMLHttpRequest on the main thread. It is bad for the user experience.

It would be nice if we could link to a page on MDN which explains why this is bad and what authors can do about it...

Comment 3

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Comment on attachment 8372677 [details] [diff] [review]
something like this

Review of attachment 8372677 [details] [diff] [review]:
-----------------------------------------------------------------

Also mention that it's been deprecated in the latest standard. r=me with that and Ehsan's comments.

Comment 4

[Olli Pettay [:smaug][[e-mail]]]

Not sure about MDN links. Those tend to change more often than links to specs. And a link to a spec makes it more clear that this isn't just about FF, but all the browsers.

Perhaps
"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/"

Comment 5

[David Teller [:Yoric] - still alive but not very active]

For Deprecated.jsm, the de-facto convention is to provide either MDN links or bugzilla links. The latter doesn't really apply, but I'd go for the former.

Comment 6

[(no longer active)]

I'm fine with a link to any useful resource, doesn't have to be MDN (good point about the issue not being Firefox specific.)

Comment 7

[Olli Pettay [:smaug][[e-mail]]]

Attachment: v2

Comment 8

[Olli Pettay [:smaug][[e-mail]]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/dff86b5bbfa6

Comment 9

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/dff86b5bbfa6

Comment 10

[Kohei Yoshino [:kohei]]

https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest
https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/Using_XMLHttpRequest
https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/Synchronous_and_Asynchronous_Requests
https://developer.mozilla.org/en-US/Firefox/Releases/30/Site_Compatibility

Comment 12

[Tony Wells]

We have a large client written in XUL and it relies heavily on synchronous requests.  The reason is the server presents itself as a collection of SOAP services which then call API calls.  When communicating with the server we may have to make several SOAP calls to the server in order to get all the data and we need those to happen in a certain order and the user not being able to interact with the client until the data is loaded isn't a bug, it's a feature.  This could be worked around in the client but would be a total pain in a client that zipped up is over 1M.  

Is there any way that synchronous requests can stick around?  Maybe if the client is launched using the -chrome argument or through a preference?

Comment 13

[(no longer active)]

(In reply to comment #12)
> Is there any way that synchronous requests can stick around?  Maybe if the
> client is launched using the -chrome argument or through a preference?

I think all of the downsides of synchronous XHR apply to chrome and content equally, so I see no reason to favor chrome loaded content here, especially since that would mean that add-ons can trigger this behavior and cause bad user experience no matter which web page our users visit.  So I suggest you consider moving away from using sync XHR.

Comment 14

[Kohei Yoshino [:kohei]]

(In reply to Tony Wells from comment #12)
> Is there any way that synchronous requests can stick around?  Maybe if the
> client is launched using the -chrome argument or through a preference?

A possible solution: Promise + async requests
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise

Comment 15

[Kohei Yoshino [:kohei]]

Or Worker + sync requests
https://developer.mozilla.org/en-US/docs/Web/Guide/Performance/Using_web_workers

Comment 16

[saty]

Hi there, please do NOT deprecate sync-loading of a resource, it *is* useful in some situations, where, as has been pointed out, using async with post-load callbacks is a PAIN IN THE A**. I load pieces of my program as-needed, from multiple locations (urls). Within a single function, I do this multiple times, for ex:

loadFile(fileA);
// do something with its contents, eg. parse, eval parts of it..
loadFile(fileB);
// do something with fileB's contents
..

I need loadFile to BLOCK while fileA is being fetched, and later, for fileB to do likewise. I do not want to load fileA asynchronously, then place the rest of the code in a callback, and within THAT callback, do another nested async-load callback, etc. I prefer the simplicity of what I indicated above, it has been working beautifully well, until, starting with FF30, there is the deprecation warning starting to appear. How a developer chooses to load (sync vs async) is up to them, and to the users (who will complain if the page becomes quite unresponsive) - the browser should not heavy-handedly dictate "best practices" (in my case, async-loading is NOT best case, it is a needless work-around). Please clean up the warning to remove the word 'deprecated', and, please DO NOT DEPRECATE this quite useful capability!!

Thanks,
Saty

Comment 17

[saty]

Meant to say above, '...in my case, async-loading is NOT best PRACTICE' (not 'best case'), sorry.

Comment 18

[David Teller [:Yoric] - still alive but not very active]

saty, you should take a look at comment 14 + http://taskjs.org/ and at comment 15. This is much better than using the synchronous API.

Comment 19

[saty]

Thanks for your reply, David. I did look at comments 14 and 15 (and played around with web workers a bit, even prior to that) before posting. I hadn't come across taskjs.org, thanks for that - looks 'promising' (pun).

I am in the middle of creating an application, and am busy with writing higher level code (compared to sync-fetching, which I have encapsulated into a blockAndFetch() call that has been working 100% well so far), and would like what I already have, to "just work" (don't want to be distracted by re-writing the loading code). 

Also, I'm aware of LAB.js etc (for guaranteed loading of files in specific order), but again, I just want <myXHRObj>.open("GET", <myURL>, false) to just work in the main thread!! 

So, question for you - will this sync-loading functionality be eventually deprecated completely?

Thanks,
Saty

Comment 20

[Anne (:annevk)]

We do want to remove this API at some point in the future, yes.

Comment 21

[Olli Pettay [:smaug][[e-mail]]]

The aim is to remove sync XHR from the main thread once the usage of it will be rare enough.
I guess it will take anything from one to five years.

Bug 558972 has some more background to this, see for example Bug 558972 comment 7.

Comment 22

[delphiajones]

Sorry, I come to this discussion late.

What statistics and metrics do you have that show end users experience detrimental effects?
Please provide a link to the discussion of detrimental effects from "sync XHR" function.

I would like tools to monitor something, anything, that reveals to me that my clients experience detrimental effects.

Is this an arbitrary decision to remove "sync XHR" function in the future?  By what means do you determine that this functionality needs to be removed?  What is the harm of maintaining this functionality?

Comment 23

[Olli Pettay [:smaug][[e-mail]]]

See the link in Bug 558972 comment 7.

And all the major browser vendors have agree that sync XHR in the main thread should be
removed if just possible.

Comment 24

[delphiajones]

Hi Olli, I read contents of your link.  Did I get this correctly:

a) the page locks up when "synch XHR" fails.

So, the page is worthless anyway if the sync fails.  Client moves on.

b) some browsers fail if the "sync XHR" fails.

So, the page is worthless; browser should handle any fail state without crashing.

c) browser processes stop until sync is resolved as either complete or fail.

So, let the browser process stop.  If detrimental to user's experience then web developers have an option to re-write their code; no need to have code re-write forced by removal of functionality. Concern is being focused only on browser efficiency, not efficiency of the the whole client - server - web developer picture. Without web development resources or server resources, who cares if the browser is efficient? 

My anecdote: six years using "sync XHR" ( started with IE6 and Firefox 2 )  with acceptably short browser lag time in displaying results.  My option will be to have lag time and increased resource use on my server instead of the client's browser.  For my sites, programmer resources needed to engineer an "async XHR" are unavailable.  My clients will experience detrimental effects when I have to shift work from their browser to my server.

Comment 25

[Paul Irish]

> Not sure about MDN links. Those tend to change more often than links to specs. And a link to a spec makes it more clear that this isn't just about FF, but all the browsers.

I would recommend against pointing developers to the specification. It's not a document that is focused on describing more detail about this brand new console warning they're looking at. Plus, the moment any developer sees a block of IDL, you've probably lost them. 

I would recommend you point developers to the really well-crafted https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/Synchronous_and_Asynchronous_Requests

Comment 26

[Chris Graham]

Okay, I appreciate that it isn't exactly Mozilla deprecating this, it's the spec authors, but here's my perspective anyway...

Of course, for most cases using sync is lazy. I just went through our codebase and corrected some cases of laziness. I appreciate the kick in the ass to improve responsiveness.

However, there are legitimate cases where you have to bend over backwards to do async, where sync really is better. Usually if you actually *intend* to lock up the UI thread. Sometimes a request needs to be completed before it is valid to work in the page again. Here are some examples...

a) Something represented in the UI is deleted. We need to update the UI state because further work with that UI state would be undefined. We can't delete from the UI early because AJAX could potentially fail (e.g. permission error, connection error, save conflict) - or because maybe to refresh the UI state we need a server response.
Workaround would be to either implement some fake modal system (either screen-wide, or locking fields), or to "backtrack" an instant removal, but it's over-complex to do, compared to locking for ~100ms.

b) The result of the AJAX action is to change what is being edited, so further edits while AJAX is happening will get overwritten when AJAX responds back. Examples: retrieving auto-saves for an opened form, doing auto-filters of a form field.

c) During something inherently already linearised, such as in an onsubmit handler, you have to make various AJAX calls in order to define the return state of that handler.
Workaround would be to make submission fully JS controlled using .submit(), but that's a big step in some situations.

Of course there are always workarounds. But the programmer (engineer) should get to choose the best way to approach the problem, not have to do a really complex workaround (which may create knock-on issues, such as additional bugs, extra download weight, extra implementation cost, greater complexity for people themeing a CMS).

I recognise the desire to make the browser responsive. Would a better approach not be to have a browser progress-bar/quasi-modal API that tied into XMLHttpRequest, and therefore deprecate use of XMLHttpRequest synchronous only when the developer has not tied in the progress API.

Generally I find it an annoyance that JS is supplanting default browser behaviour, where it could be better integrating with it. Basic progress management and state management are a good example where JS solutions are kludgy and over-complex, while a browser API would make things really simple and consistent.

Comment 27

[Franz J Fortuny]

(In reply to delphiajones from comment #24)

This is to manifest my complete agreement with what has been said by dlphiajones.

This sync request functionality SHOULD NOT BE deprecated, ever.

Good sites will only use it on rare situations, where circumstances mandate it. Also, in Intranets and in private or semi private web applications, the user's "Experience" will need to "suffer" a frozen browser once in a while, simply not allowing to continue doing something that is no longer trustable.

This is probably something that was started by geeks related to Node.js, who love this opening of 100 connections and put the CPU's to do task switching a million times, causing real overhead and more time to respond.

It is possible to make 98% of all ajax requests asynchronous and that is probably what most good programmers and web system designers will do, but this deprecation of functionality only because of the COMMERCIAL DANGER posed to browser brands about the user "maybe" feeling that the browser brand is the wrong part... This is, frankly, a game of money-go-round.

Today, applications that used to run in desktop programs, are being redesigned to run in browsers. The browsers have become the operating systems. In the past, a call to a SQL engine sometimes would halt, freeze, the application; what else was there to do? If the database engine was frozen, then something was already wrong enough to continue. Does anybody really believe that making the user believe that "everything is OK ... (except nothing is working, but you can't know that, because you are a minor)" is an attitude of SIMULATION, of totally unnecessary politeness.

When something has gone wrong, everybody whose work depends on what has gone wrong should be immediately notified, not lied about the problem.

Deprecating this is an act of rudeness, an imposition, an arbitrary decision reached at by god-complex persons. Sorry, but that is the way a lot of us here see it!

Comment 28

[port25]

Zealots... Zealots everywhere! DO NOT LET THE FANATICS REMOVE SYNCHRONOUS XMLHTTPREQUEST!!!

I see the same people over and over again --religiously-- explaining to all of us "noobs" how we should not use synchronous requests, eval, and all sorts of other "bad practices". The problem is these people tend to work on websites, and websites alone; so, of course they would never need to use these things (they also tend to use nothing but jQuery). I on the other hand, like many others, almost never use JS to code simple websites. We use it to write transcompilers, frameworks, bootstrap code, and internal --non customer facing-- tools. These projects sometimes require the use of these "bad" features. For instance: I recently worked on a JS framework (meant to be used for internal projects where responsiveness was not a priority) that needed to be as small as possible. So, there was a huge bit of JS that was not needed 99% of the time; So what did I do? I created a getter, and in the accessor I check if the code is loaded, if not, I load it synchronously, eval it, and then return the generated object. What, it takes 250ms, MAYBE, to load? Oh well, it is not client-facing, we do not care as a company, and we do not need, OR WANT, you telling us we should, you crazy crazy zealots. 

REMEMBER: Nobody likes the best practices police. Nobody!

Comment 29

[ahmet]

I agree that synchronous requests are detremental to user experience. So are characters that are too small, ads that cover a page, Image files that are too large, or code that ends up with long computation loops.
All these are the responsibility of the programmer, not the foundation or the creator of the tool.
This is analougous to say that loop variables will be limited to 1,000,000 or image sizes uploaded on a web page will be limited.

The programmer should have the responsibility of deciding when to use synch requests and when not.

Plus, the entire world does not revolve around Web presentations. 
I have an application that runs ovenight and updates databases, using a web page and javascript as a convenient user interface to start the process. Why should I complicate a process unnecessary because a group decided that they would like to "enforce" better programming ?

Comment 30

[D Merrick]

I agree entirely with the above sentiments, and that it should be up to the programmer, and that last poster ahmet expressed it very nicely. Synchronous fetches have a lot of uses, often on company intranets, where a user just clicks a shortcut and a report appears as a webpage, and you need a sequence of database fetches where the result of one fetch composes the next fetch, which is by far simplest to do with a sequence of synchronous requests. A console warning should be sufficient, but removal of the option would be a lamentable step for what is a simple and important functionality to a great many of us. Some reports may only get run once a year and one really doesn't want to have to jump extra hoops and zigzags to make them run. d

Comment 31

[Ian Nartowicz]

Is the deprecated message being generated for sync XHR from chrome?  I'm reading a local file in an addon using synchronous XMLHttpRequest and I'm not seeing the message.