An approved `document.requestStorageAccess` will include cookies in the subsequent XHR requests. However, in many cases, it'd be much easier to simply reload the iframe once the storage access has been approved. This seems to fit well within the intent of `requestStorageAccess` API. This especially helps cases that rely on server-side rendering.
<rdar://problem/43445160>
Thanks! We've received other requests on allowing persisted storage access on same-origin navigations of the iframe.
Thanks, John! Please notice that this wouldn't only be useful for a clean internal page state, but also security-specific headers such as CSP config.
RE: navigations: this would certainly be helpful. For this report, however, I intentionally narrowed the scope as much as possible in hopes that this would be more agreeable and possibly faster to implement.
1(In reply to Dima Voytenko from comment #4) > RE: navigations: this would certainly be helpful. For this report, however, > I intentionally narrowed the scope as much as possible in hopes that this > would be more agreeable and possibly faster to implement. As stated, I'm talking about iframe navigations, not top frame navigations. Reloading the iframe is an iframe navigation.
> I'm talking about iframe navigations, not top frame navigations. I'm likewise talking about iframe navigation/reload. Not sure where confusion has come from. Are iframes in Safari not observing CSP headers?
(In reply to Dima Voytenko from comment #6) > > I'm talking about iframe navigations, not top frame navigations. > > I'm likewise talking about iframe navigation/reload. Not sure where > confusion has come from. Are iframes in Safari not observing CSP headers? I'm commenting on "RE: navigations: this would certainly be helpful. For this report, however, I intentionally narrowed the scope as much as possible …" Your scope is for iframe reloads which are iframe navigations. I can see that a reload would preserve the whole URL and not just the origin, but the significant change request is whether same-origin iframe navigations should be allowed or not.
New title to reflect the proposed change.
Created attachment 348574 [details] Patch
The style checker error about "Inline functions should not be in classes annotated with WEBCORE_EXPORT" is not applicable. The whole class is marked for export and has several inline functions, including the one I'm adding two parameters to.
Attachment 348574 [details] did not pass style-queue: ERROR: Source/WebCore/loader/FrameLoaderClient.h:169: Inline functions should not be in classes annotated with WEBCORE_EXPORT. Remove the macro from the class and apply it to each appropriate method, or move the inline function definition out-of-line. [build/webcore_export] [4] Total errors found: 1 in 15 files If any of these errors are false positives, please file a bug against check-webkit-style.
I will add another correctness step to one of the test cases.
Created attachment 348664 [details] Patch
Attachment 348664 [details] did not pass style-queue: ERROR: Source/WebCore/loader/FrameLoaderClient.h:169: Inline functions should not be in classes annotated with WEBCORE_EXPORT. Remove the macro from the class and apply it to each appropriate method, or move the inline function definition out-of-line. [build/webcore_export] [4] Total errors found: 1 in 16 files If any of these errors are false positives, please file a bug against check-webkit-style.
Comment on attachment 348664 [details] Patch Thank you, Alex!
Comment on attachment 348664 [details] Patch Clearing flags on attachment: 348664 Committed r235569: <https://trac.webkit.org/changeset/235569>
All reviewed patches have been landed. Closing bug.