686481 - onUnload Asynchronous AJAX calls aren't fired when window closes

Status: RESOLVED INVALID

(Core :: DOM: Networking, defect, P3)

Description

[gec.producto]

Attachment: ajax_onunload_test.zip

User Agent: Mozilla/5.0 (Windows NT 6.0; rv:6.0.2) Gecko/20100101 Firefox/6.0.2
Build ID: 20110902133214

Steps to reproduce:

We have noticed that AJAX asycnchronous calls associated to the unload event are not sent after window is closed. 

We have prepared a demo in the attached file. 
Steps to follow:

1. Unzip contents into a folder
2. Open index.html with Firefox 4.x or above
3. Click on "Open Async Call Pop-up" link. A pop-up appears
4. Close window
5. Nothing happens on main window

If you run this demo in FF 3.6 and prior versions, IE6, IE7,IE8 and IE9 or Chrome, you will get a message "Async AJAX Call Done!!!", which is the expected behaviour.

If you run the same steps but using "Open Sync Call Pop-up" link in step 3 you will get a "Synchronous AJAX Call Done!!!" message on the main window. This works correctly in all the browsers we have tested so far.



Actual results:

No AJAX call is done when closing the window


Expected results:

After the pop-up is closed the AJAX call should be performed. This is the behaviour we get in all the major browsers and this is what Firefox used to do until FF 4.0. None of the next versions behaves as expected (we have tested up to the last nightly build)

Comment 1

[(mostly gone) XtC4UaLL [:xtc4uall]]

Confirmed against Mozilla/5.0 (Windows NT 5.1; rv:9.0a1) Gecko/20110913 Firefox/9.0a1 ID:20110913030846.

For Mozilla/5.0 (Windows NT 5.1) AppleWebKit/535.3 (KHTML, like Gecko) Chrome/16.0.880.0 Safari/535.3 it doesn't work at all.

For Opera/9.80 (Windows NT 5.1; U; Edition Next; en) Presto/2.9.196 Version/12.00 only clicking the "Fire unload function" Link within the Popup make the "AJAX Call Done" Texts appear.

Comment 2

[Josh Matthews [:jdm]]

Is this a dup of bug 661739?

Comment 3

[Boris Zbarsky [:bzbarsky]]

Seems similar....

In general, an async XHR from unload should not work per spec: closing the window stops all the network connections from it.

Comment 5

[Henri Sivonen (:hsivonen)]

See bug 1773351 for some further discussion. Specifically, despite the cross-browser difference, this doesn't seem to be a high Web compat issue.

Moving to DOM: Networking rather than Networking for a decision if we want to pursue some hack to avoid canceling a request like this despite its initiation context going away.

smaug, I think there might have been discussion of special-casing XHR from this handler. Do you recall why we haven't done so?

Comment 6

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

I don't recall discussions about special casing XHR.

Comment 7

[Randell Jesup [:jesup] (needinfo me)]

@valentin - I assume this and bug 1773351 were filed because someone actually did run into this in the field, so while it may not be a major webcompat issue, it may be hit occasionally, and it's unclear how often this would get noticed and tracked down.

How much work would it be for us to behave closer to Chrome/Safari?

Comment 8

[Sunil Mayya]

I don't think this bug and bug 1773351 are the same. This is related to being able to send requests onUnload event and bug 1773351 is our capability to send requests beforeunload event.
unload event is deprecated where as beforeunload event is still supported.

Hence, I would close this bug as INVALID as supporting a request during page unload is simply not supported by the spec and we have modern alternatives like fetch keepalive/sendbeacons if we want to support pushing data to the server on page unloads.