26736 2014-09-05 13:03:23 +0000 Does the final progress event need to be dispatched after readystatechange? 2016-08-12 08:45:43 +0000 1 1 1 Unclassified WebAppsWG XHR unspecified PC Linux RESOLVED WORKSFORME P2 normal --- 1 tyoshino annevk bugs glenn mike public-webapps public-webapps-bugzilla oldest_to_newest 111062 0 tyoshino 2014-09-05 13:03:23 +0000 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 111071 1 annevk 2014-09-05 15:34:12 +0000 So when progress dispatches, does readyState return 3? I don't really feel strongly about what we do here. 111091 2 glenn 2014-09-05 18:18:01 +0000 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. 111099 3 bugs 2014-09-05 20:03:30 +0000 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. 111101 4 glenn 2014-09-05 20:35:20 +0000 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. 111126 5 annevk 2014-09-06 09:49:02 +0000 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. 111129 6 glenn 2014-09-06 16:50:08 +0000 If what's in the same task as what? 111130 7 annevk 2014-09-06 17:02:40 +0000 The progress event and the readyState change. 111135 8 glenn 2014-09-07 04:43:09 +0000 (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.) 122255 9 tyoshino 2015-07-22 07:54:00 +0000 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. 122261 10 glenn 2015-07-22 13:53:07 +0000 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. 127128 11 annevk 2016-08-12 08:45:43 +0000 If this is still not what everyone wants, let's discuss it on GitHub.