16304 2012-03-10 09:39:32 +0000 DONE != DONE 2013-05-16 11:44:35 +0000 1 1 1 Unclassified WebAppsWG XHR unspecified All All RESOLVED INVALID http://dvcs.w3.org/hg/xhr/raw-file/8d4e9ccfdbd4/Overview.html#states P2 normal --- 1 glenn annevk hsteen mike public-webapps public-webapps-bugzilla oldest_to_newest 65284 0 glenn 2012-03-10 09:39:32 +0000 since DONE doesn't really mean DONE, i.e., because progress, load, and loadend are fired *after* readystatechange(DONE) is fired, it would be useful to explicitly document this curiosity by adding an informative note under the definition of DONE in section 4.6, for example: Note: for a given request life cycle, multiple events may be fired to the request object after a readystatechange event is fired signaling transition to the DONE state; more specifically, the progress, load, loadend, and abort events may be fired while in the DONE state. 66069 1 annevk 2012-03-26 17:23:19 +0000 The events are dispatched in the same task that to makes the transition DONE. The whole platform works that way. 66085 2 glenn 2012-03-26 22:21:40 +0000 >The events are dispatched in the same task that to makes the transition DONE. >The whole platform works that way. The point is that some readers may assume "DONE" really means DONE. Since that isn't the case, it helps (and certainly doesn't hurt) to add a note such as suggested below. 66107 3 annevk 2012-03-27 07:39:12 +0000 It's just kind of hard to grasp the confusion. Each state transition needs to be announced, which requires events. If when the events are dispatched readyState does not match the state transition (yet) that would be confusing. readystatechange/progress/load/loadend all dispatch at once more or less, it just depends on which model you are using which will be more relevant to you. 75688 4 annevk 2012-10-09 14:56:44 +0000 DONE means DONE. Events indicating the state is now DONE does not make that untrue and is in fact how every state-based API works. 75754 5 glenn 2012-10-09 23:44:19 +0000 (In reply to comment #4) > DONE means DONE. Events indicating the state is now DONE does not make that > untrue and is in fact how every state-based API works. I'm unsatisfied with this resolution. It would do no harm to add the note I suggested in comment #1, which would satisfy my concern and allow me to close this. 75813 6 annevk 2012-10-10 10:37:40 +0000 That note is misleading. Those events will be dispatched precisely because all is DONE. readystatechange is just one of the things signaling that, don't attach too much meaning to its name. 75819 7 glenn 2012-10-10 11:32:21 +0000 (In reply to comment #6) > That note is misleading. Those events will be dispatched precisely because > all is DONE. readystatechange is just one of the things signaling that, > don't attach too much meaning to its name. That's just the problem. I do attach a meaning to its name. DONE. And since, there are events delivered in this state, it doesn't really seem like DONE, it seems like ALMOST_DONE. I'm sure you can craft a simple note that addresses my concern and satisfies your intention. Try harder. If you don't wish to do so, I'll propose another version of the note. But it seems like it's in your court to propose a counter-proposal, and not simply reject my request. 75834 8 glenn 2012-10-10 14:40:13 +0000 Sorry, this is just silly. "DONE" means "the network request is done", not "this object will never do anything else". The spec is already perfectly clear, right in the definition of DONE: "DONE (numeric value 4) The data transfer has been completed or something went wrong during the transfer (e.g. infinite redirects)." http://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html#states 75908 9 glenn 2012-10-11 00:18:55 +0000 (In reply to comment #8) > Sorry, this is just silly. "DONE" means "the network request is done", not > "this object will never do anything else". The spec is already perfectly > clear, right in the definition of DONE: > > "DONE (numeric value 4) The data transfer has been completed or something > went wrong during the transfer (e.g. infinite redirects)." > http://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html#states There is nothing incompatible with that definition and my suggested note. Please add the note as I requested. It is non-normative and in no way contradicts the above. GM: please desist from making disparaging comments. It is inappropriate to do so. There is nothing "silly" about my reasonable request to add a note. 75911 10 glenn 2012-10-11 00:29:10 +0000 Adding a note that only says something that the spec already says with perfect clarity would do nothing but bloat the spec. Notes should explain things that aren't made clear by the normative text, not merely repeat what's already clear. 75913 11 glenn 2012-10-11 00:32:33 +0000 (In reply to comment #10) > Adding a note that only says something that the spec already says with > perfect clarity would do nothing but bloat the spec. Notes should explain > things that aren't made clear by the normative text, not merely repeat > what's already clear. A note can say anything we want it to say. When I read the spec, I found it would be more clear if a note were present to the effect I requested. It never hurts to add a note, and "spec bloat" is a red herring. Stop making excuses and just add the note, and I'll close this bug. 75914 12 glenn 2012-10-11 00:45:01 +0000 "Disagreeing with you" and "making excuses" are not equivalent. As for adding a note or not, that's Anne's decision, not mine (or yours, however many times you reopen the bug). This is no longer a productive discussion, so I'm removing myself from the CC list. 87754 13 hsteen 2013-05-16 10:05:54 +0000 Sort of related: https://www.w3.org/Bugs/Public/show_bug.cgi?id=22058 87761 14 annevk 2013-05-16 11:44:35 +0000 http://xhr.spec.whatwg.org/#states states: "The data transfer has been completed or something went wrong during the transfer (e.g. infinite redirects)." There are no implications about events in particular.