Re: ISSUE-58: XMLHttpRequest.abort() should just reset the object

Hi everyone,

There is something I still don't get with abort and XHR state. We saw 
that we think the state after an abort must be 4 == loaded. Given that, 
as a listener on the request, how can I know if a request has been 
aborted or has been loaded? As far as I can see, I can't. And it seems 
to me like an important missing feature.

If I'm not missing something, I really think this 4 state is misleading 
as it doesn't necessarly mean "loaded" as the current spec is stating. 
It means either "loaded" or "aborted".

I understand that we currently try to map to actual implementations and 
so we can't do much about it however we should try not to forbid future 
improvements in that area. So we should consider how future improvements 
could fit with the spec we are writing.

If we say abort() just reset the object (we don't talk about state 
change event), then we will have the chance in the future to add a new 
ABORTED state.

If we say we go to 4. Then no chance to add that.

In that case I would strongly argue that 4 description must be changed 
from LOADED to something like COMPLETED (described as loading happened 
or object has been aborted). And then we might add one day an 
isAborted() method or something like that on XHR to make the distinction 
between the two COMPLETED sub-state.

What do people think?

Thanks.

(I know that as a script author I can workaround the fact I'm not called 
with an ABORT state in the listener, but I really think it would be 
nicer for future spec to be warned in the listener when it happens).

Jim Ley wrote:
> 
> "Jonas Sicking" <jonas@sicking.cc>
> 
>> 1. Always go to 4 when abort is called
> 
>> We have done 1 in mozilla for years and no one (until the other week) 
>> has complained. So by that I would draw the conclusion that that is 
>> safe to do, however I reasoned the same way when it came to 
>> send-with-no-arguments and apparently a lot of people are doing that ;)
> 
> I'm strongly in favour of 1, it makes the most sense, the fact that IE 
> does not behave if abort is called in an onreadystatechange is fine, 
> that is something almost without a use case, and in those situations 
> when there are (you find out from a header that the rest of the request 
> is unwanted) you can do whatever you would do when 4 was received.
> 
> Cheers,
> 
> Jim.
> 
> 
> 


-- 
Christophe