XHR.Status = 200 when request is aborted & response is incomplete
Categories
(Core :: DOM: Networking, defect, P3)
Tracking
()
People
(Reporter: mattj, Unassigned)
Details
(Keywords: regression, Whiteboard: [necko-triaged])
Attachments
(1 file)
|
1.29 MB,
video/mp4
|
Details |
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:64.0) Gecko/20100101 Firefox/64.0 Steps to reproduce: I've created a jsFiddle to demonstrate the issue: http://jsfiddle.net/6xquL8nt/ Step 1: Using Firefox 63+, throttle your connection to "Regular 2G". This is only needed because the XHR that jsFiddle provides is so fast. (Longer running XHRs make this issue easier to reproduce.) Step 2: Open console & spam jsfiddle "Run" button until you see "aborted - Ready State = 4 Status = 200 Response = ". Actual results: XHR connection was aborted & response was incomplete yet Status was 200. Expected results: It should match the behavior of FF62 - Status should never be 200 in this case. According to Mozilla docs, status should only be 200 when a document is fully downloaded. Source: https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/responseText
I verified this issue on Windows 10 x64 with the latest Firefox release version 64.0 (64-bit) and I cannot reproduce it. Can you please test this in safe mode? Here is a link that can help you: https://goo.gl/AR5o9d. I think it will be a good idea to retest this on the latest Firefox Nightly. Here is a link form where you can download it: https://nightly.mozilla.org. If you still have the issue please create a new profile, you have the steps here: https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles?redirectlocale=en-US&redirectslug=Managing-profiles#w_starting-the-profile-manager
Hi, I was able to reproduce in ff63,64 & nightly with & without safe mode. Did you remember to throttle from network tab? Sometimes it takes several clicks to reproduce.
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:64.0) Gecko/20100101 Firefox/64.0 Build ID: 20181122182000 I manage to reproduce this on Windows 10 x64 with the latest Firefox beta version 64.0b12.
|
||
Updated•6 years ago
|
Andrea, is this something you could take a look at?
|
||
Comment 6•6 years ago
|
||
Not at the moment. I guess, this is a P3.
|
||
Comment 7•5 years ago
|
||
This seems like a dupe of bug 1508377, for which a fix just landed and should be in one of the next nightlies.
(In reply to Thomas Wisniewski [:twisniewski] from comment #7)
This seems like a dupe of bug 1508377, for which a fix just landed and should be in one of the next nightlies.
I don't think so - bug 1508377 was fixed in FF67. I can still reproduce this issue in FF67,FF68 & FF Nightly (69)
|
||
Updated•5 years ago
|
|
|
||
Comment 9•5 years ago
|
||
Interesting. Since I can't seem to reproduce this one on my end, is there any chance you could run mozregression and see where it broke after Firefox 62 for you, Matt J?
|
Reporter | |
Comment 10•5 years ago
|
||
Here's the mozregression results:
app_name: firefox
build_date: 2018-08-07 16:18:25.329000
build_file: C:\Users\mattj.mozilla\mozregression\persist\8ee7533d1e8e-shippable--autoland--target.zip
build_type: inbound
build_url: https://queue.taskcluster.net/v1/task/IATCHpZvTmC7n90qTbWqwg/runs/0/artifacts/public%2Fbuild%2Ftarget.zip
changeset: 8ee7533d1e8e338f3400eaf0001e1e414d792754
pushlog_url: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=8afec4b17d5cbe6eaf19af09941df4f1292ac9fd&tochange=8ee7533d1e8e338f3400eaf0001e1e414d792754
repo_name: autoland
repo_url: https://hg.mozilla.org/integration/autoland
task_id: IATCHpZvTmC7n90qTbWqwg
|
|
Reporter | |
Comment 11•5 years ago
|
||
|
|
||
Comment 12•5 years ago
|
||
That's very odd, because the bug fix I mentioned is supposed to fix exactly the symptoms you're describing, by adding this line to the code added in the bug you found with mozregression.
I wonder if it's just that the devtools are reading the value before that code is run?
|
|
Reporter | |
Comment 13•5 years ago
|
||
I don't think so. I was able to reproduce it without devtools and without throttling:
https://jsfiddle.net/hky3bu4a/
Basically, just run a window.stop() when readyState is 3 and you'll reproduce the issue.
|
|
Reporter | |
Comment 14•5 years ago
|
||
Thomas, were you able to reproduce with my fiddle?
|
|
||
Comment 15•5 years ago
|
||
Ah, sorry Matt J, I thought I had responded to that comment already!
Yes, your fiddle reproduces for me, and is a big help, thanks. I did some quick tests, but I'm not quite sure why the problem is happening yet. I hope to figure it out this or next week, once my plate is a bit clearer.
|
|
Reporter | |
Comment 16•5 years ago
|
||
Hi, we are still getting these errors as of the latest Firefox Nightly. Are there any plans to fix the issue?
|
||
Comment 17•5 years ago
•
|
||
Hi,
I've tested this using the latest Nightly version 74.0a1 (2020-01-10) (64-bit), Beta 73.0b2 (64-bit) and Release 72.0.1 (64-bit) for Ubuntu 18.04.3 LTS and Windows 10 pro, and I’m able to reproduce the issue. Based on this I will mark those versions as affected.
Best,
Clara
|
||
Updated•5 years ago
|
|
|
||
Comment 18•5 years ago
|
||
While I'm eager to see this fixed, given our current workload and the fact that we haven't seen any site bustage caused by this yet, I think we have to leave it as a P3. That is to say, there is no clear ETA on fixing this, but it is definitely on our radar to fix as soon as we can.
|
|
||
Updated•5 years ago
|
|
||
Updated•5 years ago
|
|
||
Updated•2 years ago
|
Description
•