Bug 288187 – Setting window.location.href aborts in-flight ajax requests in some cases

• Status: NEW
• Component: Page Loading

Setting window.location.href to a value that should not cause a page navigation aborts in-flight ajax requests.

Reproduce:
1) Initiate a async ajax request just before you are about to update window.location.href.
2) Update window.location.href to open a iOS app with a custom URL scheme.
3) The uncomplete ajax request is aborted with a "Network error", HTTP status of "0" and no response.

Results:
Take the following theoretical code example:
---
try {
  axios.get('https://google.com'); // Will throw "Network Error" with no response
} catch (error) {
  console.error('Error', error);
}
window.location.href = `bankid:///?autostarttoken=${autoStartToken}&redirect=${callbackUrl}`;
--

One could argue that you should await the async promise before opening the iOS app, which is fair and correct for the above example. However this issue also affects ajax polling that might be unlucky to be fired at the same time window.location.href is updated.
In our case we're opening an authentication app (Swedish BankID) while polling the authentication API in the background for a successful authentication so we can redirect the user to the logged in section.

Potential workarounds I'm thinking of but has of yet tested:
- Wait some time before starting to poll to increase the chance the app has launched from window.location.href
- Increase times between polling to a few seconds to decrease the chance of a poll to coincide with the launch of app through window.location.href

Expected Results:
I expect WebKit not to cancel in-flight ajax requests if window.location.href is used to launch an external app instead of page navigation.

Additional platforms:
We run SentryJS to catch all Javascript errors and for months this issue has only been reported on iOS, in both Safari and Chrome. Not a single time on PC or Android or any browser on these platforms. Which also correlates with our own testing. To me this sounds like the issue is related to WebKit in some way.
We have no data on other browsers on iOS.

Additional information:
This issue very likely affects using window.location.href for opening/downloading files too, but to me this seems less of an issue and less of a chance of occurring.

I used Axios in the theoretical example, but same issue occurs when using the inbuilt `fetch` library.

[Radar WebKit Bug Importer]

<rdar://problem/145833425>

We are also running into this problem with bankid on iOS devices for the last few months. Sometimes the network request is aborted. And sometimes, even stranger, it suddently takes something like 45 seconds to complete. When inspecting the web request, it reports that it was a "redirect" that took 45 seconds, even though no redirect took place.

Additional info: The same issue has been detected on several different projects. Neither are using Axois, but rather native fetch.

(In reply to hello from comment #3)
> We are also running into this problem with bankid on iOS devices for the
> last few months. Sometimes the network request is aborted. And sometimes,
> even stranger, it suddently takes something like 45 seconds to complete.
> When inspecting the web request, it reports that it was a "redirect" that
> took 45 seconds, even though no redirect took place.

Interesting, our requests were just cancelled.
Fyi the workaround I came up with was to add a `try catch` and see if the error thrown was a network error, if it was just continue the polling. If the same error occurs 3 times in a row I'd re-throw the error to abort the polling and show an error for the end user.
We had the same issue with the Swish app too, so implemented same workaround and works wonders.