This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Related to bug25587 but about successful case. http://xhr.spec.whatwg.org/#handle-response-end-of-file It's specified that XHR must fire the final progress event after readystatechange. Anne's comment about this change is here: http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1712.html Anne, what you had to do is to dispatch a progress event with loaded and total at the point we received all data. It's ok that the final progress event is dispatched before readystatechange dispatch as long as its loaded and total represent all data. Right? Commits: - https://dvcs.w3.org/hg/xhr/rev/5c90cb13ad25 - https://github.com/whatwg/xhr/commit/f1c744d6cb74371bbbaa4c07f17bfa9e9caa1718 FYI, here's the result of event order checking for Chrome, Firefox and IE. https://code.google.com/p/chromium/issues/detail?id=409544#c1
So when progress dispatches, does readyState return 3? I don't really feel strongly about what we do here.
I think it's fine if the final progress event is fired earlier. The important thing is that a "100% complete" progress event is always sent. If it's fired before readystatechange, it should be before state is set to DONE, so we don't have an event between the state change and the readystatechange event. I think I'd put it after step 3 ("If response is a network error..."). That way, setting the final response body (step 4) and switching to DONE (step 5) are still atomic to scripts, there are still no events between DONE and readystatechange, and this progress event happens in the same state as the other ones. It's just a last-minute progress event before any of the real end of file state changes start to happen.
I don't have strong feeling here. In my mind readyState property and readystatechange event are legacy, almost deprecated, and one should just use loadstart/progress/load/etc events always. But I agree with Glenn.
It's minor, but doing it this way should make it easier to avoid sending a redundant "complete" progress notification. If you already sent a 100% progress notification during the transfer, we're requiring that you send another one, since this one has to be after readystatechange.
Glenn, it would still be observable if it's same task or not same task. If we want same task, doing it as it is now seems the most sane.
If what's in the same task as what?
The progress event and the readyState change.
(In reply to Anne from comment #7) > The progress event and the readyState change. Not sure if that matters, though I guess it makes that simplification ("if the transfer already sent onprogress 100%, you don't have to send it again here") not work, since that message wouldn't be in the same task as this. (I guess another way implementations could avoid the duplicate onprogress would be to just not send onprogress during the transfer if loaded < total, so this is the only one that gets sent, at least if the length is known.)
100% event is always notified also by the "load" progress event. To always dispatch "100%" as "progress" progress event would benefit users who want to show progress bar by only setting up the onprogress handler. But leads to duplicate events for notification of the equivalent phenomenon. I'm leaning toward skipping the final "progress" progress event and just delivering the "load" progress event.
It's normal for multiple events to be fired for a single thing happening. Avoiding that isn't a goal--avoiding inconsistent behavior in websites because of confusing, unobvious API behavior (no 100% progress event being fired even though the task did complete) is.
If this is still not what everyone wants, let's discuss it on GitHub.