XML requests not sent, if page is immediately reloaded after the request (synchronous XMLHttpRequest)
Categories
(Core :: DOM: Networking, defect, P3)
Tracking
()
People
(Reporter: dpa-mozilla, Unassigned)
References
(Depends on 1 open bug, Blocks 1 open bug)
Details
(Keywords: parity-chrome, parity-safari, Whiteboard: [necko-triaged] webcompat:risk-moderate )
User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:86.0) Gecko/20100101 Firefox/86.0
Steps to reproduce:
I want to write a WebDAV client in HTLM/Javascript, which sends PROPPATCH calls tho the server. In this code
<html>
<body>
<button onclick="a()">A</button>
<button onclick="b()">B</button>
</body>
<script>
function a() {
var doc = document.implementation.createDocument("AMAM", "propertyupdate", null);
var req = new XMLHttpRequest();
req.open('PROPPATCH', '/');
req.send(doc);
document.location.reload(true);
}
function b() {
var doc = document.implementation.createDocument("AMAM", "propertyupdate", null);
var req = new XMLHttpRequest();
req.open('PROPPATCH', '/');
req.send(doc);
// document.location.reload(true);
}
</script>
</html>
the buttons A and B call the nearly identical functions a() and b(). b() does call PROPPATCH, a() does not.
|
||
Updated•5 years ago
|
|
||
Comment 1•5 years ago
|
||
Setting a component for this enhancement in order to get the dev team involved.
If you feel it's an incorrect one please feel free to change it to a more appropriate one.
|
||
Updated•5 years ago
|
|
||
Comment 2•5 years ago
|
||
Synchronous page navigation canceling an XHR sounds appropriate, and there is actually a "right" way to do this, which is to attach a callback to the xhr and reload the page when its ready state changes.
Resolving INVALID - OP, please let me know if there is something I am missing, like if this is actually violating a spec or something.
|
Reporter | |
Comment 3•5 years ago
|
||
As far as my code is concerned, I write it in such a way that it works with all browsers.
Yet pages (I do now know examples) which modify the data on the server with synchronous ajax call and then reload the page from the server (where the changes are rendered) will not work with FF but will function with other browsers.
|
|
||
Comment 4•5 years ago
|
||
(In reply to Дилян Палаузов from comment #3)
As far as my code is concerned, I write it in such a way that it works with all browsers.
Yet pages (I do now know examples) which modify the data on the server with synchronous ajax call and then reload the page from the server (where the changes are rendered) will not work with FF but will function with other browsers.
AJAX is short for asynchronous JS and XML - it is not synchronous :)
You can make the XHR synchronous by passing false as the third argument to open(), like this: req.open('PROPPATCH', '/', false);
This should make your code work the way you intend - the request will complete before the call to document.location.reload().
However, note that this is not a recommended practice. In general, the preferred approach here as I said in comment 2 is to attach a callback to the XHR and perform the reload when the ready state changes as you need.
|
|
||
Comment 5•5 years ago
|
||
Actually, now I'm curious - does the code you shared in comment 0 work in other browsers?
|
|
||
Comment 6•5 years ago
|
||
I tested it and indeed, your code works on Chrome. That's kind of surprising to me, and now I wonder about this from a webcompat perspective.
Anne, what do you think about this? As evident above, my instinct was that it makes perfect sense that an async XHR doesn't make contact with the destination if there is a synchronous page navigation immediately after send(), but Chrome appears to behave differently (my local server received the XHR request before the request for reloading the page).
|
||
Comment 8•5 years ago
|
||
This seems very similar to bug 896666, bug 1671309, and others. The TL;DR is that we have to revisit when we terminate fetches in response to navigation. I suspect the networking team is best suited to take that on, with the fallback being the Fission team which is in charge of navigation.
|
||
Updated•5 years ago
|
Description
•