[Webkit-unassigned] [Bug 220621] New: iOS: requests started during pending download are cancelled or fail due to "access control checks" error

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=220621

            Bug ID: 220621
           Summary: iOS: requests started during pending download are
                    cancelled or fail due to "access control checks" error
           Product: WebKit
           Version: Safari 14
          Hardware: iPhone / iPad
                OS: iOS 14
            Status: NEW
          Severity: Major
          Priority: P2
         Component: Page Loading
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: oliverjash at gmail.com
                CC: beidson at apple.com

Created attachment 417607

  --> https://bugs.webkit.org/attachment.cgi?id=417607&action=review

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).

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20210114/5e69bedd/attachment-0001.htm>