Bug 220621 – iOS: requests started during pending download are cancelled or fail due to "access control checks" error

• Status: NEW
• Component: Page Loading

[Oliver Joseph Ash]

Created attachment 417607 [details]
Screen recordings

Reduced test case with steps to reproduce:

1. Using Safari and iOS 13/14, go to https://ios-safari-download-bug.herokuapp.com/
2. Open developer tools to inspect network calls and console
3. Click the "download" link (an `a` element which uses the `download` attribute)

Expected: when the download link is clicked, we see that two requests are made in the network panel: one using `fetch` and another using an `img` element. These should be successful.

Actual: when the download link is clicked, we see that two requests are made in the network panel, however they both fail. In the console we see this error: "Unhandled Promise Rejection: TypeError: cancelled" (i.e. the `fetch` promise rejected).

It appears that any request that is started whilst the download is pending (i.e. whilst the user is viewing the modal and choosing whether to view/download/cancel) will be cancelled.

See attached screen recording (1).

Code for this reduced test case can be viewed here (branch `master`): https://github.com/OliverJAsh/ios-safari-download-bug

---

If we add a slight delay so that the requests are started later (but still during a pending download), we observe a slight difference in the behaviour.

Repeat the steps above but using https://ios-safari-download-bug-delay.herokuapp.com/ instead.

When the download link is clicked, we don't see any new network requests in the network panel, and in the console we see different errors:

- "Fetch API cannot load https://ios-safari-download-bug-delay.herokuapp.com/ping due to access control checks."
- "Unhandled Promise Rejection: TypeError: Type error"

This "access control checks" error seems like a false positive because the request being made is for the same origin as the current page *and* the downloaded file.

See attached screen recording (2).

Code for this reduced test case can be viewed here (branch `delay`): https://github.com/OliverJAsh/ios-safari-download-bug/tree/delay

---

Note that we also see another error in the console: "Failed to load resource: Frame load interrupted". However I think this is a separate problem (a different Safari bug).

[Oliver Joseph Ash]

Created attachment 417608 [details]
Screen recording 1

[Oliver Joseph Ash]

Created attachment 417609 [details]
Screen recording 2

[Oliver Joseph Ash]

Could anyone give us any clue what might be going on here? If we had some idea what exactly the problem was, it might help us find a usable/reliable workaround.

I had hoped we could workaround this by scheduling a window focus event handler when the download link is clicked, and then making the requests inside of this event handler. If I understand correctly, the download prompt/modal/dialog will blur the window and then the window will focus again when the prompt is closed. Unfortunately I've only had limited success with this—if the download response has a `content-type` response header to something other than `text/html`, e.g. something like `text/plain`, then it fails with the "access control checks" error again.


---

More observations:

- If we use a longer delay like 2500ms instead of 10ms, the requests succeed.
- If we do that *and* set the download response  `content-type` response header to something *other* than `text/html`, e.g. something like `text/plain`, then it fails with the "access control checks" error again.

[Radar WebKit Bug Importer]

<rdar://problem/73446249>

[Smoley]

Thanks for filing, I'm seeing the Unhandled Promise Rejection error on iOS 13 and the 14.4 beta as well. I'll cc some relevant folks here.

[Oliver Joseph Ash]

Does anyone have any ideas what is going on here?

[Oliver Joseph Ash]

Please can we get an update on this? At least could we get an explanation for why this is happening so we can better focus our efforts to create a robust workaround?

With the release of iOS 15, our workaround broke and yet again we need to invest more time in creating workarounds.