Re: [XHR] Event firing order. XMLHttpRequestUpload then XMLHttpRequest or reverse

On Fri, Aug 2, 2013 at 2:13 AM, Anne van Kesteren <annevk@annevk.nl> wrote:

> On Tue, Jul 30, 2013 at 10:25 AM, Takeshi Yoshino <tyoshino@google.com>
> wrote:
> > Change on 2010/09/13
> >
> http://dev.w3.org/cvsweb/2006/webapi/XMLHttpRequest-2/Overview.src.html.diff?r1=1.138;r2=1.139;f=h
> > reversed the order of event firing for "request error" algorithm and
> send()
> > method to XHRUpload-then-XHR.
> >
> > send() (only loadstart event) and abort() method are still specified to
> fire
> > events in XHR-then-XHRUpload order. Is this intentional or we should make
> > them consistent?
>
> We should make them consistent in some manner. Firing on the main
> object last makes sense to me. It also makes some amount of conceptual
> sense to do the reverse for when the fetching starts, but I feel less
> strongly about that.


In the spec, we have three "cancel"s
- cancel an instance of fetch algorithm
- cancel network activity
- cancel a request

The spec says "Cancel a request" is an abort error which fires events in
XHR-XHRUpload order, but abort() fires events in XHR-XHRUpload order. It
was confusing so I filed this bug. First and at least, I'd like to make
this clear.

What does "cancel a request" correspond to?

Re: loadstart, I don't have strong opinion, too.