52

I was just wondering what could happen if, while an ajax call is being executed, an alert is prompted to the user, in the browser window.

Let's say, for example, that I have an ajax call

$.ajax({
    url: ...,
    type: GET/POST,
    ...
    success: function(data){
        console.log(data);
    },
    error: ...
});

that takes long time to complete (10 sec). While the call is executed, a simple javascript alert is thrown

alert("hello!");

What happens for example if:

  1. ajax call starts
  2. ajax call fetching data
  3. alert is shown
  4. ajax call returns data (alert window is still open!)

Knowing that JS is single threaded I know that the script execution will halt, I was just wondering what happens to the ajax call/response if the alert window is not closed "in time".

I hope I was clear enough and that this is not a "dummy" question. Thank you

Axel
  • 13,939
  • 5
  • 50
  • 79
BeNdErR
  • 17,471
  • 21
  • 72
  • 103
  • +1 Good question. I do use alert as a poor man's break point, and never encountered a problem, however.. I can't remember to have ever waited longer then a regular connection-time-out before resuming the script by clicking OK.. I *think* the browser (seen as a 'wrapper'/'driver' for the javascript-engine and layout-engine) will/should continue to operate and just halt the javascript-engine, that way the ajax-data would be queued for further execution. But that's not a proper (referenced and real-life) answer.. – GitaarLAB May 22 '14 at 08:26
  • I also use alerts to prompt messages to the user.. and I think is not a very good solution :( – BeNdErR May 22 '14 at 08:31
  • 1
    side-note, one can always override `window.alert` (after using them as mockup-messages/breakpoints during prototyping) to (drive) a custom function. – GitaarLAB May 22 '14 at 08:35
  • didn't think of that.. nice one. – BeNdErR May 22 '14 at 09:03
  • An alert is no different from a function that takes a long time to run. Think of what happens if: 1. ajax call starts, 2. right after ajax call, call a very_time_consuming_function, 3. ajax call returns data before very_time_consuming_function is finished, (now what?) 4. very_time_consuming_function completes, 5. now what? Now you see that alert or not does not make any difference at all. – Stephen Chung May 28 '14 at 02:57

2 Answers2

60

This isn't exactly hard to try and see... but the answer is that the alert will take priority and hold up the flow of execution.

Upon closing the alert, and assuming the AJAX request has completed while the alert was open, then the success function will be processed (or error function).

Note that the AJAX request will continue to run while the alert is shown (so a long running AJAX can process while the alert is open), but it is just that your script cannot continue handling the request until the alert is closed.

Here is a working example, notice that the data isn't written to the console until the alert is closed.

Another point to be aware of is that after the alert closes, the script will continue with the rest of the function (the code immediate after the alert) before the AJAX response is handled. This helps demonstrate what I mean

musefan
  • 47,875
  • 21
  • 135
  • 185
  • It's a good answer, also see http://stackoverflow.com/questions/598436/does-an-asynchronous-call-always-create-call-a-new-thread. What is important to understand is that if the alert is called after AJAX request started, it will not block the completion of that event (the request) but the processing of its event handler will wait until the alert is closed. – marekful May 22 '14 at 08:27
  • @AD7six: What are you going on about? – musefan May 22 '14 at 08:28
  • @AD7six: Why won't it? [What about this](http://jsfiddle.net/fwrn3/1/) that shows it starting before the alert – musefan May 22 '14 at 08:32
  • if you remove the alert from your last example, the script will still run the code immediate after the alert before the `success` cb.. I think the code will follow the event queue already established when the code was launched, not caring about the alert – BeNdErR May 22 '14 at 09:02
  • @BeNdErR: Oh yes of course, I wasn't suggesting the `alert` was causing the code to run first, just wanted to make it clear that you should expect the function to finish before the response is processed, just in case you might be relying on the response being handled first – musefan May 22 '14 at 09:09
  • Ah! If the ajax request handler contains an alert(), the content of the alert showne is going to be updated! – Jeremy D May 29 '14 at 09:42
  • The text is going to change, this is what I meant. – Jeremy D Jun 01 '14 at 14:05
11

The HTTP request will continue to run and be processed in the background.

When the JS event loop becomes free, the readystatechange handler will fire.

Some intermediate ready states may be skipped because the event loop was busy while that state was true.

Quentin
  • 914,110
  • 126
  • 1,211
  • 1,335
  • Will the response connection be kept open and wait for the alert to be closed? – BeNdErR May 22 '14 at 08:38
  • 1
    Maybe if pipe-lining is turned on. As I said in the answer "The HTTP request will continue to run and be processed in the background.", if the normal behaviour for the response/request is to close the connection when the response is received, then the connection will be closed. – Quentin May 22 '14 at 08:40
  • @Quentin, that's what I suspected. I do wonder.. is there some spec/rfc that requires this behavior (so one can safely conclude any reasonable browser does this)? – GitaarLAB May 22 '14 at 08:44
  • @Quentin Sorry to bother you, but I dont get one thing.. You say "he HTTP request will continue to run and be processed in the background." how can it run in background if the single-thread is blocked by the alert? Do you mean the server keeps sending the response, waiting for the client to accept it? – BeNdErR May 22 '14 at 10:16
  • 2
    XMLHttpRequest is a native control with a JS interface. It doesn't depend on the JS event loop (other than to communicate with JS, which is why doing so is event driven) – Quentin May 22 '14 at 10:18
  • 3
    @BeNdErR The important thing to understand is that even though Javascript is single-threaded, the browser itself is not. – Barmar May 28 '14 at 04:20