XmlHttpRequest cancelled when the page is unloaded

[perrog]

Hi!

What is the expected behaviour when you send an XmlHttpRequest just
before the page is about to unload? I'm sending a XmlHttpRequest on an
onClick event, and I can inspect that the request is sent and
responded in the network traffic, but my onReadyStateChange handler is
notified with an error.

It took me some time to deduce what the real problem was, and I think
my browser begins to tear down the XmlHttpRequest when the page is
about to unload. Therefore, the request is sent, but the browser
cancels before the response is processed and onReadyStateChange is
notified with an error.

I'm using Safari/KHTML.

I searched W3's draft specification,
http://www.w3.org/TR/XMLHttpRequest/
but could not find any answer.

Should the browser wait on XmlHttpRequest completion before the page
is unload? Or should the browser cancel pending XmlHttpRequests when
the page is about to unload?

[pcx99]

pe****@gmail.com wrote:

Hi!

What is the expected behaviour when you send an XmlHttpRequest just
before the page is about to unload? I'm sending a XmlHttpRequest on an
onClick event, and I can inspect that the request is sent and
responded in the network traffic, but my onReadyStateChange handler is
notified with an error.

It took me some time to deduce what the real problem was, and I think
my browser begins to tear down the XmlHttpRequest when the page is
about to unload. Therefore, the request is sent, but the browser
cancels before the response is processed and onReadyStateChange is
notified with an error.

I'm using Safari/KHTML.

I searched W3's draft specification,
http://www.w3.org/TR/XMLHttpRequest/
but could not find any answer.

Should the browser wait on XmlHttpRequest completion before the page
is unload? Or should the browser cancel pending XmlHttpRequests when
the page is about to unload?

From my experience (which does not include Safari), a user's navigation
requests will trump anything save for modal dialog boxes (alert, prompt,
etc). That means, no matter what your program is doing, it will be
halted in its tracks when the user navigates away.

HOWEVER, a synchronous Ajax request is "modal" in that it will stall
your script until it receives an answer back from the server. I don't
know if it will interfere with user navigation requests the way a
prompt/alert box will, but if you're desperate you might want to try
using a synchronous Ajax request instead of an asynchronous request.

--
http://www.hunlock.com -- Musings in Javascript, CSS.
$FA

[pcx99]

pcx99 wrote:

From my experience (which does not include Safari), a user's navigation
requests will trump anything save for modal dialog boxes (alert, prompt,
etc). That means, no matter what your program is doing, it will be
halted in its tracks when the user navigates away.

HOWEVER, a synchronous Ajax request is "modal" in that it will stall
your script until it receives an answer back from the server. I don't
know if it will interfere with user navigation requests the way a
prompt/alert box will, but if you're desperate you might want to try
using a synchronous Ajax request instead of an asynchronous request.

And no sooner do I write this than I stumble across an article which
tests this very thesis.

http://www.oreillynet.com/xml/blog/2..._browsers.html

Firefox will stall, opera and IE do not stall, and Firefox considers the
stall a bug, or defect, and is fixed in the nightly builds which means
the next release of Firefox will not stall waiting for synchronous requests.

The article was dated only yesterday so I do have a little excuse ;)

--
http://www.hunlock.com -- Musings in Javascript, CSS.
$FA

[Laurent Bugnion [MVP]]

Hi,

pcx99 wrote:

pcx99 wrote:

> From my experience (which does not include Safari), a user's
navigation requests will trump anything save for modal dialog boxes
(alert, prompt, etc). That means, no matter what your program is
doing, it will be halted in its tracks when the user navigates away.

HOWEVER, a synchronous Ajax request is "modal" in that it will stall
your script until it receives an answer back from the server. I
don't know if it will interfere with user navigation requests the way
a prompt/alert box will, but if you're desperate you might want to try
using a synchronous Ajax request instead of an asynchronous request.

And no sooner do I write this than I stumble across an article which
tests this very thesis.

http://www.oreillynet.com/xml/blog/2..._browsers.html
Firefox will stall, opera and IE do not stall, and Firefox considers the
stall a bug, or defect, and is fixed in the nightly builds which means
the next release of Firefox will not stall waiting for synchronous
requests.

The article was dated only yesterday so I do have a little excuse ;)

Careful here. The *browser* will not freeze, but the *current page* will
freeze. So actually, your first answer is totally correct IMHO, in that
a sync AJAX call behaves very much like an "alert", and the current
script execution is blocked until the response arrives (or until an
error occurs).

This is still a reason to recommend not using sync calls except in
special cases. Having the current page blocked for a noticeable time is
not user friendly, and can create unwanted side effects.

HTH,
Laurent
--
Laurent Bugnion [MVP ASP.NET]
Software engineering: http://www.galasoft-LB.ch
PhotoAlbum: http://www.galasoft-LB.ch/pictures
Support children in Calcutta: http://www.calcutta-espoir.ch