XHR aborting in onloadstart handler cause load is dispatched(!) and loadend is dispatched twice
Reported by
lego1223...@gmail.com,
Feb 8 2017
|
|||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0 Steps to reproduce the problem: 1. create xmlhttprequest object 2. attach event handlers with console.log to all events 3. attach a handler with abort() to loadstart event 4. send request What is the expected behavior? I think that after abort() is called, onload handler must not be called and loadend handler must be called once. What went wrong? In the test1.html example(where server side accepts all request http methods, simply waits 3 seconds and then replies) we get the next log: 1. get/delete with abort() in onloadstart: loadstart u_progress u_abort u_loadend progress abort loadend after 3 seconds we get also: progress load loadend 2. head with abort() in onloadstart: loadstart u_progress u_abort u_loadend progress abort loadend after 3 seconds we get also: load loadend 3. post/put with abort() in onloadstart: loadstart u_progress u_abort u_loadend progress abort loadend u_loadstart u_progress after 3 seconds we get also: progress load loadend 4. post/put with abort() in upload.onloadstart: loadstart u_loadstart u_progress u_abort u_loadend progress abort loadend u_progress after 3 seconds we get also: progress load loadend abort() in onprogress handlers works right. But mobile chrome browser in addition to dispatching onload() eat onabort event: 1. get/delete with abort() in onloadstart: loadstart after 3 seconds we get also: progress load loadend 2. head with abort() in onloadstart: loadstart after 3 seconds we get also: load loadend 3. post/put with abort() in onloadstart: loadstart u_loadstart u_progress u_load u_loadend after 3 seconds we get also: progress load loadend 4. post/put with abort() in upload.onloadstart: loadstart u_loadstart u_progress u_load u_loadend after 3 seconds we get also: progress load loadend Did this work before? N/A Does this work in other browsers? In firefox an ie this works right. Safari on ipad has the same problem. Opera 42.0.2393.517 and chrome mobile (55.0.2883.91) has this problem too with some specifics. Chrome version: 56.0.2924.87 Channel: n/a OS Version: Flash Version: Shockwave Flash 24.0 r0
,
Feb 8 2017
****Bulk Edit**** Setting as P1 for test team to prioritize in triaging.
,
Feb 9 2017
Just for clarification: Opera 42.0.2393.517 and chrome mobile (55.0.2883.91) has this problem too with some specifics. must be read as: Opera 42.0.2393.517 has this problem too. Chrome mobile (55.0.2883.91) has this problem with some specifics(pointed out above).
,
Feb 9 2017
This looks like out of scope for TE, hence adding the respective label for it to triage further.
,
Feb 10 2017
,
Feb 10 2017
Thanks much for a detailed report, would it be possible & reasonably easy for you to test with something based on M57? A couple of fixes around abort() (including its use from within loadstart handlers) have landed recently.
,
Feb 10 2017
No problem, if i could found something based on M57 for windows. May be you can give me a download link?
,
Feb 10 2017
Awesome, anything from a beta channel (or fresher) from https://www.chromium.org/getting-involved/dev-channel should currently get you >= M57.
,
Feb 10 2017
Done. I've tested Beta(57.0.2987.37), Dev(58.0.3004.3) and Canary(58.0.3007.0). All this versions has 2 strange moments like a chrome on android - abort event isn't fired and load event is fired. You can see this in the attachment(column order can be changed with help of "change order" link and "redraw" button).
,
Feb 11 2017
Thanks; I can't reproduce the lack of "abort" events locally. I wonder if your test rig is issuing too many concurrent XHRs and you are running into effects because of that (i.e., the network layer will throttle concurrent connections (opened via XHRs) to prevent undesirable script behavior). Attached is a version of #3's test1.html that has the option of chaining the tests. Could you try running that and see if that behaves differently?
,
Feb 14 2017
Hm. Sequential test show, that abort() handler is fired in chrome >57. But about parallel test - is this normal to miss abort events in this case? I attached test-xhr patch(with prevention of double loadend event and test finish indication by button disabled/enabled state).
,
Feb 16 2017
ok, thanks - i'd say that this confirms there is no real issue surrounding abort() not dispatching abort events. Other than progress events, XHR shouldn't throttle their dispatching, so any event handler that call abort() should (sync'ly) dispatch and call the abort listener/handler. You may want to debug your testrig, i.e., in combination with the above also consider the possibility that the cache might cause observed event sequences to differ in the parallel case. Marking as wontfix (works as intended.)
,
Mar 1 2017
Thank you! We will use chrome >57 version to not get double loadend event dispatching. About abort events, if i understood correctly, when many concurrent xmlhttprequests exist, chrome too busy to dispatch abort events and request complete before abort event can be dispatched, so it's not dispatched at all. Do i understand you right?
,
Mar 2 2017
Thanks, I expect those repeats to be gone, so please report a new issue if you experience otherwise. Re: question - if you do these XHR tests concurrently, make sure you also request uniquely-named resources, so that the network cache won't confuse and upset event ordering & timing. It's just too complex a system to expect deterministic behavior from if you got concurrent request throttling to contend with as well. |
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by lego1223...@gmail.com
, Feb 8 2017