This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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.
The events are dispatched in the same task that to makes the transition DONE. The whole platform works that way.
>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.
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.
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.
(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.
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.
(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.
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
(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.
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.
(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.
"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.
Sort of related: https://www.w3.org/Bugs/Public/show_bug.cgi?id=22058
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.