Bug 23933 – XMLHttpRequest doesn't work while submitting a form (useful for progress tracking)

• Component: Page Loading
• Status: NEW

[Matthew Van Andel]

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();}
xhr.open("GET",strURL,true);
xhr.send(null);

...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 (1.0.154.48), 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.

[Matthew Van Andel]

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.

[Mark Rowe (bdash)]

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.

[Matthew Van Andel]

I created an example page our web server. http://sites.lakeave.org/WebKitBug_XMLHttpRequest/

[Alexey Proskuryakov]

*** Bug 19901 has been marked as a duplicate of this bug. ***

[Alexey Proskuryakov]

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.

[Richard Cooper]

(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+.

Regards,
Richard C.

[Alexey Proskuryakov]

<rdar://problem/7095678>

[Frank]

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.

[Frank]

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.

[Alexey Proskuryakov]

(In reply to comment #8)
> For us the workaround is not a option.

Why is it not an option?

[Frank]

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.

[Ben]

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.

[Alexey Proskuryakov]

This bug already mentions a workaround - instead of using the antiquated mechanism of uploading files via form submission, upload with XMLHttpRequest.

[Ben]

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).

[Ben]

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.

[Alexey Proskuryakov]

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.

[Alexey Proskuryakov]

*** Bug 137817 has been marked as a duplicate of this bug. ***

[Ben]

6.5 years and counting...

[Brady Eidson]

(In reply to comment #18)
> 6.5 years and counting...

Hi Ben,

Did you see this?

(In reply to comment #16)
> 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.

Just curious if you did ever start a thread about the issue you're concerned about that is not the same as this bug. Or, perhaps, did you file a new bug for that different issue?

[Ben]

(In reply to comment #19)
> 
> Hi Ben,
> 
> Did you see this?
> 
> (In reply to comment #16)
> > 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.
> 
> Just curious if you did ever start a thread about the issue you're concerned
> about that is not the same as this bug. Or, perhaps, did you file a new bug
> for that different issue?

Hi, Brady; thanks for the follow-up.

Yes, I saw Alexey's comment, but didn't see it fit to respond.

To be clear, my initial comment was in response to and regarding *this* bug (POST requests preventing XHR requests).

I asked about the same problematic behavior regarding GET requests mostly in an effort to determine whether or not both bugs have the same root-cause. The reception was less than warm, at which time I lost interest in spending more time documenting either problem.

I ended-up using the shoddy iframe workaround for both POST and GET requests, which allows XHR requests to function as they do in every other browser-kit I've tested.

I would really like to eliminate the iframe solution in favor of a "proper" XHR solution, for both verbs. I am not inclined to maintain separate code just to workaround this limitation in Webkit, and so have had to use the "least common denominator" that works in every browser that we support.

But you raise a good point: I should file a separate bug for the GET equivalent. I will update this bug with a link if and when I take the time.

Thanks again.

I used the iframe workaround on a project a few years ago, but when I tried to set up the same code in a new project today, I found that it no longer works in the current version of Safari. Changes in the iframe content when reloading it to update the progress, or any other changes made to element styles with JavaScript, no longer render after the form submission begins. The functionality still runs, but the page rendering doesn't update to reflect the changes. This is described further in a couple StackOverflow posts:

http://stackoverflow.com/questions/22043493/unable-to-make-style-changes-to-the-dom-after-form-submit-in-safari

http://stackoverflow.com/a/23772089/462162

The other suggested workaround was to do the file upload with XMLHttpRequest instead of with a traditional form submission. It would be a pretty big job to rework all my forms, with a low cost/benefit ratio since they all work just fine now except for the inability to show an upload progress. Is there any hope at this point for allowing AJAX requests or style changes after a form is submitted?

Actually I just tried this in Chrome for Mac, and the original AJAX method of showing upload progress and the iframe workaround both worked fine. So maybe this is a Safari-specific problem and not Webkit. Or maybe it is a difference in the Webkit versions used in the two browsers.

My Chrome user agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.116 Safari/537.36

My Safari user agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_3) AppleWebKit/601.4.4 (KHTML, like Gecko) Version/9.0.3 Safari/601.4.4