Bug 23933 - XMLHttpRequest doesn't work while submitting a form (useful for progress tracking)
: XMLHttpRequest doesn't work while submitting a form (useful for progress trac...
Status: NEW
Product: WebKit
Classification: Unclassified
Component: Page Loading
: 525.x (Safari 3.2)
: All All
: P2 Normal
Assigned To: Nobody
: InRadar
Depends on:
  Show dependency treegraph
Reported: 2009-02-12 14:06 PST by Matthew Van Andel
Modified: 2014-10-18 23:27 PDT (History)
12 users (show)

See Also:

Example of bug in C#.NET 3.5 Website (11.09 KB, application/xhtml+xml)
2009-02-13 10:47 PST, Matthew Van Andel
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Matthew Van Andel 2009-02-12 14:06:04 PST
Summary: XMLHttpRequest does not send/recieve data when executed following a Submit button click that triggers server-side behavior.

When an functional XMLHttpRequest is being executed in a loop (successfully), and a Submit button is clicked that posts to the server (such as with a server task that takes a very long time to execute), the XMLHttpRequest immediately stops working, even while the loop continues to be executed.

For instance, this code...

xhr.onreadystatechange = function(){xhrCatch();}

...works perfectly in any loop until a submit button is clicked. After the submit button is clicked, each loop will return an exception for xhr.readyState or xhr.status (as if they were null/undefined). Likewise, xhr.responseText and xhr.responseXML will also be null... as if the request was either not sent or not received. However, the function xhrCatch() triggered by xhr.onreadystatechange will still be executed ONCE after the button click... but still with the invalid values for responseText, readyState, etc.

This was discovered when attempting to create an Ajax progress bar for a long-executing task triggered when a Submit button is clicked. The server writes to an XML file during each loop while AJAX reads from the XML file and displays the results on the page. Both the server action and the Ajax are triggered onclick. The progress bar is updated constantly until the task finishes and the page is redirected (server redirect).

HOWEVER, even if the XMLHttpRequest loop is started on the page load, it will work absolutely correctly (even if the XML is updated by hand) UNTIL the button is clicked, at which point it immediately stops working and returns null/undefined xhr properties.

I've been able to duplicate this on both Windows and OSX versions of Safari (3.2) as well as Chrome (, using a number of different combinations of code event handlers and buttons. Firefox, Opera, and IE work perfectly both before and after the Submit button is clicked... while with Safari and Chrome the XMLHttpRequest always stops functioning immediately after a Submit button is clicked.
Comment 1 Matthew Van Andel 2009-02-13 10:47:41 PST
Created attachment 27665 [details]
Example of bug in C#.NET 3.5 Website

This attachment is an example put together for the sole purpose of demonstrating this bug. Created in Visual Studio 2008 (compatible with Visual Web Developer), it demonstrates that Ajax works until a button is clicked that triggers server-side behavior, even though the page has not reposted.
Comment 2 Mark Rowe (bdash) 2009-03-20 16:22:22 PDT
Can you please provide a URL at which we can reproduce this problem?  Many WebKit developers don't use Windows, and of those that do few if any are familiar with C#.NET.  A live page demonstrating the problem would make it possible to observe and investigate it.
Comment 3 Matthew Van Andel 2009-03-23 09:48:22 PDT
I created an example page our web server. http://sites.lakeave.org/WebKitBug_XMLHttpRequest/
Comment 4 Alexey Proskuryakov 2009-04-02 01:47:53 PDT
*** Bug 19901 has been marked as a duplicate of this bug. ***
Comment 5 Alexey Proskuryakov 2009-04-02 01:51:06 PDT
Per bug 19901, it's not just that existing requests are stopped, but new ones don't start either.

See bug 19901 for a suggested workaround for file upload progress.
Comment 6 Richard Cooper 2009-10-26 08:12:51 PDT
(In reply to comment #5)
> Per bug 19901, it's not just that existing requests are stopped, but new ones
> don't start either.
> See bug 19901 for a suggested workaround for file upload progress.

Any idea when this will be fixed? The sugested workaround only works for Safari 4+ and we need to support 3+ and Chrome 2+.

Richard C.
Comment 7 Alexey Proskuryakov 2010-04-30 13:05:24 PDT
Comment 8 Frank 2010-07-23 13:30:47 PDT
This bug is still in Safari 5.0.  For us the workaround is not a option.  We have used a packet sniffer and once the submit button is pressed, the .open/.send no longer sends a request to the server.
Comment 9 Frank 2011-08-22 15:06:52 PDT
Testing today on a Thunderbolt phone using browser with WebKit 533.1 and Safari 5.1 AppleWebKit/534.50 and this bug is still present.  Just wanted to say that we can't find any workaround and this is still very important to us.
Comment 10 Alexey Proskuryakov 2011-08-22 16:18:47 PDT
(In reply to comment #8)
> For us the workaround is not a option.

Why is it not an option?
Comment 11 Frank 2011-10-01 12:45:19 PDT
As we understand, the workaround is to use iframes which we tried and did work for Safari and Chrome.  It did not "work" for IE and we need a solution that is not conditional on such a grand scale.  For IE every time you request an update from the server the audio clicks which is normal for IE and OK if it does that once when you load a page but in this config it does it every 1/2 second when we query the server for an update.
Comment 12 Ben 2012-04-09 21:55:49 PDT
I just ran into this issue.

Quite frankly, the fact that this issue was reported over three years ago and to this day remains unfixed is a real black-eye for the Webkit group.

I hate to sound unappreciative, but this is too major a bug to go unaddressed for so long.

The fact that I'm unable to make AJAX requests while a file upload is being processed in any Webkit-based browser is disheartening. Even IE handles this situation as expected (at least when using jQuery to handle the AJAX).

And we are told to work around the issue by using a dynamically-generated iFrame. What an elegant solution...

If the half-hearted excuse is "works for me", then I'm prepared and willing to provide a reproducible test-case and respond to any questions.
Comment 13 Alexey Proskuryakov 2012-04-09 22:44:03 PDT
This bug already mentions a workaround - instead of using the antiquated mechanism of uploading files via form submission, upload with XMLHttpRequest.
Comment 14 Ben 2012-04-25 18:00:41 PDT
And if I want to GET (download) a file, and prompt the user to save it?

I ask because the same issue exists with GET requests as with POST requests: Webkit-based browsers appear to refuse to carry-out AJAX requests while a file is being downloaded -- whether via conventional GET request or via XMLHttpRequest.open('GET', url).
Comment 15 Ben 2012-04-27 08:14:38 PDT
To elaborate, if I have a link (anchor element with href attribute) that points to a binary file (a download of some kind), and I attach an on-click event to the element that triggers AJAX GET requests at some interval, those requests are not acted upon until the GET request for the binary file is completed.

It bears mention that modern browsers seem to examine the request headers and do not change the window location if the file appears to be binary. As such, the user never "sees" the download page, but is presented with the download file dialog once the GET request has completed. This is a nice feature. For browsers that do not implement this behavior, it can be forced with the preventDefault() JavaScript function.

In any case, what's the workaround when the request method is GET instead of POST? As far as I am aware, there is no "receive()" equivalent to the send() method.
Comment 16 Alexey Proskuryakov 2012-04-27 09:06:40 PDT
It's not great to discuss workarounds for downloading a file in a bug that was filed about submitting forms and progress tracking (there is a lot of progress tracking for downloads already). I suggest moving this part of discussion to webkit-help mailing list.
Comment 17 Alexey Proskuryakov 2014-10-18 23:27:35 PDT
*** Bug 137817 has been marked as a duplicate of this bug. ***