Re: [XHR] Event firing order. XMLHttpRequestUpload then XMLHttpRequest or reverse
On Sat, Oct 5, 2013 at 1:26 AM, Anne van Kesteren wrote: > On Fri, Oct 4, 2013 at 3:12 PM, Takeshi Yoshino > wrote: > > Sorry. I included network by mistake. I wanted to understand the abort > error > > well. > > > > Q: cancel by abort() is abort error? > > It's not the same condition. abort() has its own set of steps. > Although we might be able to merge these and probably should... > > > OK. > > Q: any kind of network activity cancellation not due to network/timeout > are > > abort error? > > No. > OK. I didn't understand what you meant by "end user" correctly. Never mind.
Re: [XHR] Event firing order. XMLHttpRequestUpload then XMLHttpRequest or reverse
On Fri, Oct 4, 2013 at 3:12 PM, Takeshi Yoshino wrote: > Sorry. I included network by mistake. I wanted to understand the abort error > well. > > Q: cancel by abort() is abort error? It's not the same condition. abort() has its own set of steps. Although we might be able to merge these and probably should... > Q: any kind of network activity cancellation not due to network/timeout are > abort error? No. -- http://annevankesteren.nl/
Re: [XHR] Event firing order. XMLHttpRequestUpload then XMLHttpRequest or reverse
On Fri, Oct 4, 2013 at 8:46 PM, Anne van Kesteren wrote: > On Thu, Oct 3, 2013 at 6:35 AM, Takeshi Yoshino > wrote: > > On Tue, Sep 3, 2013 at 9:00 PM, Anne van Kesteren > wrote: > >> This is the end user terminate, correct? > > > > Yes. So, this includes any kind of event resulting in termination of > fetch > > algorithm (network, termination by some user's instruction to UA)? > > No, if you look at > http://xhr.spec.whatwg.org/#infrastructure-for-the-send%28%29-method > "If the end user cancels the request" is about the end user, "If there > is a network error" is about everything else. > > > Sorry. I included network by mistake. I wanted to understand the abort error well. Q: cancel by abort() is abort error? Q: any kind of network activity cancellation not due to network/timeout are abort error?
Re: [XHR] Event firing order. XMLHttpRequestUpload then XMLHttpRequest or reverse
On Thu, Oct 3, 2013 at 6:35 AM, Takeshi Yoshino wrote: > On Tue, Sep 3, 2013 at 9:00 PM, Anne van Kesteren wrote: >> This is the end user terminate, correct? > > Yes. So, this includes any kind of event resulting in termination of fetch > algorithm (network, termination by some user's instruction to UA)? No, if you look at http://xhr.spec.whatwg.org/#infrastructure-for-the-send%28%29-method "If the end user cancels the request" is about the end user, "If there is a network error" is about everything else. > Thank you. Just alphabetical name is fine. Added. -- http://annevankesteren.nl/
Re: [XHR] Event firing order. XMLHttpRequestUpload then XMLHttpRequest or reverse
Sorry for the delay. On Tue, Sep 3, 2013 at 9:00 PM, Anne van Kesteren wrote: > On Tue, Sep 3, 2013 at 9:18 AM, Takeshi Yoshino > wrote: > > In the spec, we have three "cancel"s > > - cancel an instance of fetch algorithm > > - cancel network activity > > These are the same. Attempted to clarify. > > Verified that the order of events are the same for abort() and abort error. Thanks for factoring out termination algorithm. It's clearer now. > > > - cancel a request > > This is the end user terminate, correct? > Yes. So, this includes any kind of event resulting in termination of fetch algorithm (network, termination by some user's instruction to UA)? > Would you like to be > acknowledged as "Takeshi Yoshino"? If you can give me your name in > kanji I can include that too. See e.g. > http://encoding.spec.whatwg.org/#acknowledgments for some examples. > > Thank you. Just alphabetical name is fine. > See http://xhr.spec.whatwg.org/ for the updated text. And > https://github.com/whatwg/xhr/commits for an overview of the changes. >
Re: [XHR] Event firing order. XMLHttpRequestUpload then XMLHttpRequest or reverse
On Tue, Sep 3, 2013 at 9:18 AM, Takeshi Yoshino wrote: > In the spec, we have three "cancel"s > - cancel an instance of fetch algorithm > - cancel network activity These are the same. Attempted to clarify. > - cancel a request This is the end user terminate, correct? > 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. I aligned abort() with end user abort now. Would you like to be acknowledged as "Takeshi Yoshino"? If you can give me your name in kanji I can include that too. See e.g. http://encoding.spec.whatwg.org/#acknowledgments for some examples. See http://xhr.spec.whatwg.org/ for the updated text. And https://github.com/whatwg/xhr/commits for an overview of the changes. -- http://annevankesteren.nl/
Re: [XHR] Event firing order. XMLHttpRequestUpload then XMLHttpRequest or reverse
On Fri, Aug 2, 2013 at 2:13 AM, Anne van Kesteren wrote: > On Tue, Jul 30, 2013 at 10:25 AM, Takeshi Yoshino > 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.
Re: [XHR] Event firing order. XMLHttpRequestUpload then XMLHttpRequest or reverse
On Thu, Aug 1, 2013 at 6:13 PM, Anne van Kesteren wrote: > On Tue, Jul 30, 2013 at 10:25 AM, Takeshi Yoshino 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. Anyone opinions on this? Would be good to sort out and I don't really care one way or another. -- http://annevankesteren.nl/
Re: [XHR] Event firing order. XMLHttpRequestUpload then XMLHttpRequest or reverse
On Tue, Jul 30, 2013 at 10:25 AM, Takeshi Yoshino 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. -- http://annevankesteren.nl/
