When using the fetch API, the response object has a url property which is the final URL that ended up being accessed.
The fetch polyfill populates this property by looking at the responseURL property of the XHR.
However, because FakeXHR, does not set this property, pretender will not work with systems that use fetch and the url property of the subsequent Response. (like this one
This small change copies over the the url argument passed to open and uses it as the responseURL of the XHR.
Theoretically, the responseURL could be different than the opened url, but only if a re-direct happened. As far as I can tell though, FakeXHR doesn't handle re-directs so this shouldn't be an issue.
cowboyd
commented
5 years ago
When using the fetch API, the
responseobject has aurlproperty which is the final URL that ended up being accessed.The fetch polyfill populates this property by looking at the responseURL property of the XHR.
However, because FakeXHR, does not set this property, pretender will not work with systems that use fetch and the
urlproperty of the subsequentResponse. (like this oneThis small change copies over the the
urlargument passed toopenand uses it as theresponseURLof the XHR.Theoretically, the responseURL could be different than the opened url, but only if a re-direct happened. As far as I can tell though, FakeXHR doesn't handle re-directs so this shouldn't be an issue.