NS_ERROR_ABORT in XMLHttpRequest when run in parallel to another XMLHttpRequest that is raced
Categories
(Core :: Networking: Cache, defect)
Tracking
()
People
(Reporter: mattcoz, Unassigned, NeedInfo)
References
(Blocks 1 open bug)
Details
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/111.0
Steps to reproduce:
I've been having issues with many XMLHttpRequests failing with NS_ERROR_ABORT. The common thread is that there is another XMLHttpRequest occurring in parallel and it is raced instead of returning from the cache. I don't understand why a request is raced or is not raced, so I'm having trouble consistently reproducing it. But, the requests are always successful when the parallel request is not raced, and they always fail when it is. So it seems very likely that this is the reason. I've disabled RCWN for now and I haven't seen any NS_ERROR_ABORT failures since.
|
||
Comment 1•2 years ago
|
||
Moving this to Core so that the devs could have a look over it. If this is not the correct component, please feel free to change it to a more appropriate one. Thanks.
|
||
Comment 2•2 years ago
|
||
Could you capture some HTTP logs while reproducing the problem?
Thanks!
|
||
Comment 3•2 years ago
|
||
Like this is a major issue. Like major major. Depending on the cases this bugs can render a site useless, creating js errors where there are actually none. It wasn't hard to find a case where you can test the issue at hand when RCWN is enabled. Easily found a site as an example, which is unrelated to my work:
https://toom.de/
You get almost all the goodies there. NS_BINDING_ABORTED, NS_ERROR_UNEXPECTED.
If this doesnt get resolved in the next minor update by at least disabling RCWN per default as a hotfix solution, this will be the end of my long term relation with Firefox as a default browser. Furthermore I'm going to inform our customer service now to advise customers to use another browser, if they run into issues with their Firefox version.
|
|
||
Comment 4•2 years ago
|
||
I am unable to reproduce on https://toom.de/
Could you capture some HTTP logs and send them to necko@mozilla.com?
Thanks!
|
|
||
Comment 5•2 years ago
|
||
I'll have to do a comparison from home. It may have something to do with some messed up corporate restriction. Strangely today even disabling rcwn didnt do the trick, which it did yesterday and today it doesnt matter anymore and the errors always occur. Though there will be a major difference in my test settings given I don't have a Windows notebook.
|
||
Comment 6•2 years ago
|
||
Closing this bug as there is no response from the reporter. Feel free to open the bug once the requested information is available.
Description
•