User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36 Steps to reproduce: Interrupt/navigate away from a page while a XHR request is in progress. To reproduce: Sample app at https://my-awesome-project-2bb19.firebaseapp.com/ fetches a data file to estimate latency, then fetches it again asynchronously and reloads itself before the data is fully read. Open link in a browser with caching disables, look for "uncaught exception: Invalid response length for code 200" messages in the console. Started happening in FF63. Possibly linked to https://bugzilla.mozilla.org/show_bug.cgi?id=1007109 Actual results: XHR changes ready state to Completed, status 200. However the response test is empty. Expected results: XHR should either have the complete data in state Completed/200 or it should indicate status != 200.
Actual user agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:63.0) Gecko/20100101 Firefox/63.0
Using the sample app. I've tested on: 65.0a1 20181122220059 64.0b11 20181119162153 63.0.3 20181114214635 Also tested on osx 10.13.6 for: 65.0a1 2018-11-22 63.0.3 2018-11-14 I can see the 2nd XHR request getting 200 ok status on all the versions above (cache disabled). The "uncaught exception: Invalid response length for code 200" is displayed for 2nd xhr call. I've also looked at 60.3.0esr 20181017185317 61.0.2 20180807170231 62.0.3 20181001155545 and the 2nd XHR request is getting code 200ok as well, but the The "uncaught exception: Invalid response length for code 200" is not displayed anymore. AIUI, the XHR request code 200 is not a regression and the console error seems to me like an improved error logging, therefore I will pass the option to set "regression" for this bug's whiteboard until further investigation is being done.
status-firefox63: --- → affected
status-firefox64: --- → affected
status-firefox65: --- → affected
Component: Untriaged → DOM
OS: Unspecified → All
Product: Firefox → Core
Hardware: Unspecified → All
Is there a chance you can use https://mozilla.github.io/mozregression/ to figure out when it changed? I'll CC some people who've made recent changes to our XHR code.
Keywords: regression, regressionwindow-wanted
Priority: -- → P2
mozregression identified one change, seems pertinent: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=23889c258042e274783b442e2ed570e836978a9e&tochange=8ee7533d1e8e338f3400eaf0001e1e414d792754
Thanks, Sebastian! Thomas, were your changes in bug 1362354 expected to have the effect that's been reported here?
Yes, the fix in that bug will detect an aborted XHR and handle it like an aborted XHR, calling the RequestErrorSteps of the XHR spec, which resets the response to a network error: https://xhr.spec.whatwg.org/#request-error-steps I do this because the spec says to do it in the "handle errors for response" steps: > Otherwise, if response’s aborted flag is set, then run the request error steps for event abort and exception "AbortError" DOMException. But perhaps I shouldn't just be calling the request error steps for that specific case? Anne, did I misinterpret the text for this specific case, where the user navigates away while an XHR is ongoing? Was the intent for that case to not reset the response to a network error, but keep whatever response body has been downloaded so far? Either way, we will probably want to change the abort-after-stop() test so that it confirms that the response is indeed what we expect it to be after the abort events are sent.
Flags: needinfo?(twisniewski) → needinfo?(annevk)
It's generally unclear to me how "navigating away" works and how interoperable it is across browsers. Aborting seems good, but it really depends on web compatibility. It does seem like a bug though that status still returns 200 if the internal response is set to a network error. status should return 0 in that case.
Hey Thomas - is this something you can tackle fixing?
Likely too late to fix in 64 even in a dot release but let release management know if you land a patch and want to uplift.
status-firefox64: affected → wontfix
status-firefox66: --- → affected
status-firefox65: affected → wontfix
status-firefox-esr60: --- → unaffected
status-firefox66: affected → fix-optional
status-firefox67: --- → affected
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/autoland/rev/9c46b805faeb properly update XHR status when one is aborted because of an NS_BINDING_ABORTED confition such as window.stop(); r=baku
Status: NEW → RESOLVED
Last Resolved: 10 days ago
status-firefox67: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla67
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/15850 for changes under testing/web-platform/tests
Whiteboard: [necko-triaged] → [necko-triaged][wptsync upstream]
status-firefox66: fix-optional → wontfix
You need to log in before you can comment on or make changes to this bug.