{"id":858,"date":"2014-06-11T18:45:35","date_gmt":"2014-06-11T16:45:35","guid":{"rendered":"http:\/\/blog.visisoft.de\/yalst\/?p=858"},"modified":"2015-05-28T22:59:49","modified_gmt":"2015-05-28T20:59:49","slug":"ajax-on-unloading-a-web-page","status":"publish","type":"post","link":"https:\/\/www.yalst.de\/en\/ajax-on-unloading-a-web-page\/","title":{"rendered":"AJAX on web page unloading"},"content":{"rendered":"

AJAX on web page unloading<\/h4>
<\/div><\/div><\/div>\n\n

\"JavaScript-logo\"<\/p>\n

TL;DR <\/strong>On page unload<\/em>\u00a0AJAX network requests are sent by all browsers if – contrary to the general advice – the synchronous<\/em> flavour of \u00a0XMLHttpRequest<\/code>\u00a0(SJAX) is used.<\/p>\n

\u00a0The Problem of sending goodbye data on page unload<\/h4>\n

occurs often that a single page web application (SPA) needs to change the state in its cloud end (clean up resources, close network connections…) when a user quits the application (i.e. she closes the browser window).
\nThe obvious choice is to subscribe for the DOM window’s unload<\/code> and\/or beforeunload<\/code> events with handler methods and trigger a remote signal on a server via XMLHttpRequest<\/code> (i.e. AJAX).\u00a0The result of that signalling is usually of no interest to the SPA front end (browser page).
\nHowever what can be done in these handlers has always depended on the various browser implementations.<\/p>\n

The beforeunload Event Handler<\/h4>\n

can prompt the user to remain in the SPA showing a native UI dialog while JavaScript execution is halted. For creating network requests the same constraints as with the unload<\/code> handler apply, except for the Chrome browser.<\/p>\n

In the unload Event Handler<\/h4>\n

the UI is already gone. Therefore UI operations (alert, window.open,…) do not make sense here.\u00a0How much JavaScript execution time remains is unknown. However to deduct that operations in here have to be fast<\/em> and avoid all blocking JavaScript instructions all together is wrong<\/em>!
\nTests (see the table below) show that many browsers do not issue network requests if done asynchronously.<\/p>\n

The Solution<\/h4>\n

is to use AJAX<\/em> without the first ‘A’<\/em> or S(ynchronous)JAX<\/em> if there were such a thing. Thus simply setting the async<\/code> flag of the XMLHttpRequest.open<\/code> method to false<\/code>\u00a0ensures the network request is fired by all browsers. But never mind about that blockingness<\/em> of the JavaScript instruction, because we are not interested in the response anyway!<\/p>\n

A Test Case<\/h4>\n

is kept in jQuery<\/a>\u00a0and can be found under\u00a0jquery\/test\/data\/ajax\/onunload.html<\/a><\/p>\n

Test Results<\/h4>\n<\/div><\/section>\n
<\/th>\"\"<\/th>\"\"<\/th>\"\"<\/th>\"\"<\/th><\/tr>
<\/th>v.10<\/th>v.36<\/th>v.30<\/th>v.7<\/th><\/tr>
AJAX (async = true)<\/td>ok<\/td>ok<\/td>fails<\/td>?<\/td><\/tr>
AJAX (async = true)
\nafter dismissed a beforeunload prompt<\/td>		ok<\/td>fails sometimes<\/td>fails<\/td>?<\/td><\/tr>
SJAX (async = false)<\/td>ok<\/td>ok<\/td>ok<\/td>ok<\/td><\/tr><\/tbody><\/table><\/div>