Bug 220621

Summary: iOS: requests started during pending download are cancelled or fail due to "access control checks" error
Product: WebKit Reporter: Oliver Joseph Ash <oliverjash>
Component: Page LoadingAssignee: Nobody <webkit-unassigned>
Status: NEW ---    
Severity: Major CC: achristensen, beidson, bfulgham, cdumez, kkinnunen, krollin, mark.lam, oliverjash, smoley, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: Safari 14   
Hardware: iPhone / iPad   
OS: iOS 14   
Attachments:
Description Flags
Screen recordings
none
Screen recording 1
none
Screen recording 2 none

Description Oliver Joseph Ash 2021-01-14 03:41:22 PST 
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).
Comment 1 Oliver Joseph Ash 2021-01-14 03:42:45 PST 
Created attachment 417608 [details]
Screen recording 1
Comment 2 Oliver Joseph Ash 2021-01-14 03:43:06 PST 
Created attachment 417609 [details]
Screen recording 2
Comment 3 Oliver Joseph Ash 2021-01-17 09:08:56 PST 
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.
Comment 4 Radar WebKit Bug Importer 2021-01-21 03:42:17 PST 
<rdar://problem/73446249>
Comment 5 Smoley 2021-01-29 12:33:07 PST 
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.
Comment 6 Oliver Joseph Ash 2021-02-03 06:38:50 PST 
Does anyone have any ideas what is going on here?
Comment 7 Oliver Joseph Ash 2021-09-27 11:12:35 PDT 
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.