The default bug view has changed. See this FAQ.

XMLHttpRequestUpload's load() fires too late




6 years ago
3 years ago


(Reporter: Egmont Koblinger, Unassigned)


Firefox Tracking Flags

(Not tracked)




6 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US) AppleWebKit/534.16 (KHTML, like Gecko) Chrome/10.0.648.134 Safari/534.16
Build Identifier: Firefox 4.0-rc1 , end of section 3.6.9 says:
[...] When it is said to make upload progress notifications run these steps: [...] If the request entity body has been successfully uploaded [...] Dispatch a progress event called load at the XMLHttpRequestUpload object.

Based on this, I believe the XMLHttpRequestUpload's load() event should fire as soon as the _upload_ part of the request is completed. Firefox, however, waits until the response is received.

Reproducible: Always

Steps to Reproduce:
1. Do an AJAX POST with the upload property and its onload defined.
2. Make sure to send it to a server that responds slowly (e.g. has a sleep(10) in PHP)
3. Watch the event getting fired.
Actual Results:  
The event is fired when the server completes sending its response (that is, after 10 seconds in this example).

Expected Results:  
The event should fire as soon as the payload has been uploaded to the server, even if the response is not yet arriving.

Note 1: The onprogress event of upload fires a couple of times during upload, with growing "loaded" value, but it's not fired when the upload completes (i.e. when "loaded" reaches "total"). If one draws an upload progress bar, it evenly goes up to almost 100% but not quite, and there it stops for the amount of time required by the server to process the request. I believe the role of the onload event is to fill this gap, so that the JS code can know when the data has been completely uploaded, and it begins waiting for the server's response. Obviously, there are the main XMLHttpRequest's onprogress and onload events that correspond to download activities, XMLHttpRequestsUpload's ones should reflect the upload only.

Note 2: Google Chrome 10 does it as expected.
This is a duplicate, but the short of it is that until the server starts responding we don't know whether we have _successfully_ uploaded.  Depending on the server response, we may in fact have to do the upload all over again.  So what we're doing is exactly what the spec says to do, and Chrome is just lying about when it knows the upload is successful...
Whiteboard: DUPEME
Last Resolved: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 637002


3 years ago
Whiteboard: DUPEME
You need to log in before you can comment on or make changes to this bug.