Christophe Jolif wrote:
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 that is indeed true we need to fix it I agree. Is there a sensible
value we could set .status to for example?
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.
The reason is that there might be content out there that depends on it.
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.
Even if we say 'just reset' there is no way to add it later IMHO. I
don't see this as a problem either way though since we shouldn't design
the next revision around readystatechange but rather around other
solutions. readystatechange is a pretty poor design anyway.
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.
That might not be a bad idea. Though hopefully .status could be that
distiction.
/ Jonas
