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
: WebKit
Page Loading
: 525.x (Safari 3.2)
: All All
: P2 Normal
Assigned To:
: http://sites.lakeave.org/WebKitBug_XM...
: InRadar
  Show dependency treegraph
Reported: 2009-02-12 14:06 PST by
Modified: 2012-04-27 09:06 PST (History)

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


You need to log in before you can comment on or make changes to this bug.

Description From 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 From 2009-02-13 10:47:41 PST -------
Created an attachment (id=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 From 2009-03-20 16:22:22 PST -------
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 From 2009-03-23 09:48:22 PST -------
I created an example page our web server. http://sites.lakeave.org/WebKitBug_XMLHttpRequest/
------- Comment #4 From 2009-04-02 01:47:53 PST -------
*** Bug 19901 has been marked as a duplicate of this bug. ***
------- Comment #5 From 2009-04-02 01:51:06 PST -------
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 From 2009-10-26 08:12:51 PST -------
(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 From 2010-04-30 13:05:24 PST -------
------- Comment #8 From 2010-07-23 13:30:47 PST -------
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 From 2011-08-22 15:06:52 PST -------
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 From 2011-08-22 16:18:47 PST -------
(In reply to comment #8)
> For us the workaround is not a option.

Why is it not an option?
------- Comment #11 From 2011-10-01 12:45:19 PST -------
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 From 2012-04-09 21:55:49 PST -------
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 From 2012-04-09 22:44:03 PST -------
This bug already mentions a workaround - instead of using the antiquated mechanism of uploading files via form submission, upload with XMLHttpRequest.
------- Comment #14 From 2012-04-25 18:00:41 PST -------
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 From 2012-04-27 08:14:38 PST -------
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 From 2012-04-27 09:06:40 PST -------
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.