New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 321241 link

Starred by 36 users

Issue metadata

Status: Fixed
Owner:
Closed: Dec 2013
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug



Sign in to add a comment

XHR Requests not sent in window unload

Reported by brian.wy...@oracle.com, Nov 19 2013

Issue description

Chrome Version : 31.0.1650.57 (Official Build 235101)
URLs (if applicable) :
Other browsers tested:
    Chrome 30: OK
    Firefox 23: OK
    IE 9/10: OK

What steps will reproduce the problem?
1. Setup an XHR request to occur during the window unload event
2. Refresh the page or navigate away via a link on the page

What is the expected result?
The XHR request is sent successfully, the server sees the request and can handle it.

What happens instead?
No request is sent out to the server, and in Chrome, a DOMException is thrown, with the following details:
    code: 19
    message: "A network error occurred."
    name: "NetworkError"

Please provide any additional information below. Attach a screenshot if
possible.

One weird note: If the user closes the tab/browser, the XHR goes through fine. But if they refresh the page or click a link to another page in the application, the XHR will not fire.

Our use case: we're saving some metadata/preferences for the current page in a synchronous XHR request sent during the window unload event (we use jQuery for AJAX, but I've also tried using simple native XHR requests, and non-synchronous ones; none gets sent during the unload event). We haven't seen any problems in other browsers, and versions of Chrome prior to 31 work just fine as well.

I can setup a simple little client/server in nodejs to demonstrate this if needed, just looking for feedback first.
 

Comment 1 by Deleted ...@, Nov 19 2013

Whatever you put inside the unload event will not work. Even simple alert("Hello") doesn't work.
Labels: Needs-Feedback
brian.wyant@, Thanks so much for filing. If possible, could you please provide a sample file to reproduce the same? and also which OS you are using?
Sure.  See https://github.com/bmwyant/ChromeTest for a sample server/client that demonstrates the issue.

I'm using Ubuntu 12.04.3 LTS, and typically compare the Chrome 31 build mentioned above, along with Chromium 30.0.1599.114 (Developer Build 30.0.1599.114-0ubuntu0.12.04.3)
I can confirm this issue on Windows 7 x64 and Chrome 31.0.1650.57.

Just do a synchronous xmlhttprequest (post) in window.onunload and you will get "NetworkError" in response.  The ajax request is never sent.  We have an installation of 1500 users and all have the same problem with 31.0.1650.57.

This is a big issue in the enterprise as things like record unlocking are typically performed using this event coupled with an ajax request.


Comment 5 by tkent@chromium.org, Nov 21 2013

Labels: Cr-Blink-XHR Cr-Blink-Loader

Comment 6 by eas...@gmail.com, Nov 21 2013

I can confirm this also, Win 7x64, Chrome 31.0.1650.57 (for me and for all our enterprise users using same version of Chrome). Any xmlhttprequest sent in window.onunload event is not sent to the server.

As mentioned in post #4, this is huge problem for our enterprise web applications, since they all rely on releasing record locks through ajax request on page unload.  

Releasing them in window.onbeforeunload is not an option for us, we provide way for users to cancel navigation away from page there, and we need to release locks only when user really chooses to leave the page.
Notice this is still unconfirmed are you all still waiting on something?

windown.onunload = function() {
        var xmlhttp = new XMLHttpRequest();
        xmlhttp.open('POST', 'your_url_here', false);
        xmlhttp.setRequestHeader("Content-type", "application/x-www-form-urlencoded");
        xmlhttp.send("");
}

The xhr will not be sent and NetworkError will occur.

Comment 8 by sigbjo...@opera.com, Nov 22 2013

ResourceFetcher::shouldLoadNewResource() returns false as its DocumentLoader differs from the active loader on the frame (the FrameLoader being in a provisional state.)

The sync request doesn't go ahead as a result.
Owner: abarth@chromium.org
Seeing the word "loader" makes me think "abarth".  Adam, can you triage?

Comment 10 by Deleted ...@, Nov 26 2013

BTW, seeing this on pagehide events as well.
Still unconfirmed? This one isn't hard to recreate, you all need something else from us end users?
Cc: rponnada@chromium.org
 Issue 322334  has been merged into this issue.
Cc: abarth@chromium.org
Owner: japhet@chromium.org
@japhet: Maybe a regression from one of your recent changes?
Status: Assigned
Best guess is https://src.chromium.org/viewvc/blink?revision=154852&view=revision, which sure doesn't feel "recent" :)
Project Member

Comment 15 by bugdroid1@chromium.org, Dec 4 2013

The following revision refers to this bug:
    http://src.chromium.org/viewvc/blink?view=rev&rev=163151

------------------------------------------------------------------------
r163151 | japhet@chromium.org | 2013-12-04T09:45:21.692605Z

Changed paths:
   A http://src.chromium.org/viewvc/blink/trunk/LayoutTests/http/tests/xmlhttprequest/resources/xmlhttprequest-in-unload-sync.html?r1=163151&r2=163150&pathrev=163151
   A http://src.chromium.org/viewvc/blink/trunk/LayoutTests/http/tests/xmlhttprequest/xmlhttprequest-unload-sync.html?r1=163151&r2=163150&pathrev=163151
   A http://src.chromium.org/viewvc/blink/trunk/LayoutTests/http/tests/xmlhttprequest/xmlhttprequest-unload-sync-expected.txt?r1=163151&r2=163150&pathrev=163151
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/fetch/ResourceFetcher.cpp?r1=163151&r2=163150&pathrev=163151

Allow resource loads inside page unload events

https://src.chromium.org/viewvc/blink?revision=154852&view=revision appears
to have inadvertently caused ResourceFetcher::shouldLoadNewResource() to return
false inside of unload events. This is because activeDocumentLoader() has
switched to the provisional document loader, but the request is coming from
the committed document loader.

Test written by sigbjornf@opera.com

BUG= 321241 
TEST=http/tests/xmlhttprequest/xmlhttprequest-unload-sync.html

Review URL: https://codereview.chromium.org/102353004
------------------------------------------------------------------------
Labels: -Needs-Feedback
Status: Fixed

Comment 17 by m.go...@gmail.com, Dec 4 2013

Is it going to be backported to beta & stable? Seems like a big deal.
Labels: Merge-Requested M-32
Status: Started
I can confirm this bug too, it even  helped us found other bug not punishable to chrome or webkit but to our reverse proxy script "missunderstood" by webkit but to be honest webkit has the wild-triumph over Firefox or IE

The reverse-proxy problem help is here for the interested ones : http://stackoverflow.com/questions/20340031/solved-webkit-browsers-post-bug-with-varnish-ajaxform-server-detects-metho

Comment 20 by kareng@google.com, Dec 5 2013

nate did this make canary?

Comment 21 by kareng@google.com, Dec 5 2013

Labels: OS-All
The patch first appears in 1730, which I think is today's canary?
We also faced this issue in normal case as well 
 xhttp = new XMLHttpRequest();
            xhttp.open("GET", fname, false);
            xhttp.send();
            xmlDoc = xhttp.responseXML;

can you please suggest in which chrome version it will get resolved . It would be great if we can get version number and the date of release.

Thanks in advance.. :)

Comment 24 by kareng@google.com, Dec 9 2013

Labels: -Merge-Requested Merge-Approved
Project Member

Comment 25 by bugdroid1@chromium.org, Dec 9 2013

Labels: -Merge-Approved merge-merged-1700
The following revision refers to this bug:
    http://src.chromium.org/viewvc/blink?view=rev&rev=163450

------------------------------------------------------------------------
r163450 | japhet@chromium.org | 2013-12-09T18:41:28.286930Z

Changed paths:
   A http://src.chromium.org/viewvc/blink/branches/chromium/1700/LayoutTests/http/tests/xmlhttprequest/xmlhttprequest-unload-sync.html?r1=163450&r2=163449&pathrev=163450
   A http://src.chromium.org/viewvc/blink/branches/chromium/1700/LayoutTests/http/tests/xmlhttprequest/xmlhttprequest-unload-sync-expected.txt?r1=163450&r2=163449&pathrev=163450
   M http://src.chromium.org/viewvc/blink/branches/chromium/1700/Source/core/fetch/ResourceFetcher.cpp?r1=163450&r2=163449&pathrev=163450
   A http://src.chromium.org/viewvc/blink/branches/chromium/1700/LayoutTests/http/tests/xmlhttprequest/resources/xmlhttprequest-in-unload-sync.html?r1=163450&r2=163449&pathrev=163450

Merge 163151 "Allow resource loads inside page unload events"

> Allow resource loads inside page unload events
> 
> https://src.chromium.org/viewvc/blink?revision=154852&view=revision appears
> to have inadvertently caused ResourceFetcher::shouldLoadNewResource() to return
> false inside of unload events. This is because activeDocumentLoader() has
> switched to the provisional document loader, but the request is coming from
> the committed document loader.
> 
> Test written by sigbjornf@opera.com
> 
> BUG= 321241 
> TEST=http/tests/xmlhttprequest/xmlhttprequest-unload-sync.html
> 
> Review URL: https://codereview.chromium.org/102353004

TBR=japhet@chromium.org

Review URL: https://codereview.chromium.org/107293006
------------------------------------------------------------------------
Status: Fixed

Comment 27 by m.go...@gmail.com, Dec 16 2013

Will this be backported to Chrome 31? It bites us in jQuery currently, see: http://swarm.jquery.org/job/2137
I don't think they're taking any changes in 31 anymore, given how far we are into its estimated 6-week life on stable.

Comment 29 by m.go...@gmail.com, Dec 16 2013

Ah, OK then. If it's in 32 and it's going to be released soon, we're fine.
I'm testing 34.0.1752.0 canary is this problem still exists. When for example posting a form to upload a file and trying to use XHR to check to status of the file upload, using a server side progress bar, XHR returns "A network error occurred" in the JavaScript console. This problem is not fixed in 34.0.1752.0 canary. If any developers need access to a test page, just send me an e-mail and I'll mail you a link and you can check for yourself.
Either a link or a snippet of the calls on the XMLHttpRequest object would be helpful.

What event are you are you listening to in order to send the XHR? Is the XHR sync or async?
The XHR is synchronously. I'll email you a link to a page where you can check for yourself.
@karloslarlundin, your issue is related but subtly different (in that it's after a new navigation has begun, but not in an unload event). Please open a new bug, and feel free to link it here.
Ok. I have opened a new bug here: https://code.google.com/p/chromium/issues/detail?id=330254

Would be great if you could confirm the bug.

Comment 35 by m.go...@gmail.com, Jan 7 2014

It seems Chrome weren't so much into the 32 release when this was fixed... Almost a month passed since Dec 9.

Comment 36 by Deleted ...@, Jan 27 2014

Is there a workaround for this bug?

Comment 37 Deleted

Comment 38 by m.go...@gmail.com, Feb 4 2014

Yes, it's fixed in Chrome 32.
Is anyone still seeing this problem in Chrome 32?  
Im running 32.0.1700.107, and experiencing the same behavior on a client's site. 
Chrome 32 definitely fixed it for me. Unfortunately, I can't check my exact version at the moment.

Comment 41 Deleted

Comment 42 by m.go...@gmail.com, Feb 15 2014

@timothy jQuery has a unit test for that:
https://github.com/jquery/jquery/blob/954966e08d26bf29700711dc4d7b56198350e862/test/unit/ajax.js#L1541-1544
This test fails in Chrome 31 and passes on Chrome 32 so this issue is clearly fixed. If you do have an issue, it's only related but a separate one from the one that was fixed here. You should report a new issue for that.
Timothy: try using onbeforeunload instead of onload. The problem we had is that onunload seems to cancel all async XHRs before running the onunload code, and was screwing things up for us.

Comment 44 by tkent@chromium.org, Nov 27 2015

Labels: -Cr-Blink-XHR Cr-Blink-Network-XHR

Sign in to add a comment