Bug 16304 - DONE != DONE
DONE != DONE
Status: RESOLVED INVALID
Product: WebAppsWG
Classification: Unclassified
Component: XHR
unspecified
All All
: P2 normal
: ---
Assigned To: Anne
public-webapps-bugzilla
http://dvcs.w3.org/hg/xhr/raw-file/8d...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-03-10 09:39 UTC by Glenn Adams
Modified: 2013-05-16 11:44 UTC (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Glenn Adams 2012-03-10 09:39:32 UTC
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.
Comment 1 Anne 2012-03-26 17:23:19 UTC
The events are dispatched in the same task that to makes the transition DONE. The whole platform works that way.
Comment 2 Glenn Adams 2012-03-26 22:21:40 UTC
>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.
Comment 3 Anne 2012-03-27 07:39:12 UTC
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.
Comment 4 Anne 2012-10-09 14:56:44 UTC
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.
Comment 5 Glenn Adams 2012-10-09 23:44:19 UTC
(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.
Comment 6 Anne 2012-10-10 10:37:40 UTC
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.
Comment 7 Glenn Adams 2012-10-10 11:32:21 UTC
(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.
Comment 8 Glenn Maynard 2012-10-10 14:40:13 UTC
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
Comment 9 Glenn Adams 2012-10-11 00:18:55 UTC
(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.
Comment 10 Glenn Maynard 2012-10-11 00:29:10 UTC
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.
Comment 11 Glenn Adams 2012-10-11 00:32:33 UTC
(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.
Comment 12 Glenn Maynard 2012-10-11 00:45:01 UTC
"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.
Comment 13 Hallvord R. M. Steen 2013-05-16 10:05:54 UTC
Sort of related: https://www.w3.org/Bugs/Public/show_bug.cgi?id=22058
Comment 14 Anne 2013-05-16 11:44:35 UTC
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.