What happens if an alert window is shown during an ajax call?

Question

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

Millpond

+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.. – Soll

I also use alerts to prompt messages to the user.. and I think is not a very good solution :( – Millpond

side-note, one can always override window.alert (after using them as mockup-messages/breakpoints during prototyping) to (drive) a custom function. – Soll

didn't think of that.. nice one. – Millpond

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. – Folia

Answer 1

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

Parthia

It's a good answer, also see #598936. 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. – Springy

@AD7six: What are you going on about? – Parthia

@AD7six: Why won't it? What about this that shows it starting before the alert – Parthia

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 – Millpond

@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 – Parthia

Ah! If the ajax request handler contains an alert(), the content of the alert showne is going to be updated! – Epley

The text is going to change, this is what I meant. – Epley

Answer 2

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.

Parliamentarian

Will the response connection be kept open and wait for the alert to be closed? – Millpond

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. – Parliamentarian

@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)? – Soll

@Parliamentarian 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? – Millpond

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) – Parliamentarian

@Millpond The important thing to understand is that even though Javascript is single-threaded, the browser itself is not. – Obreption