Clarify browser specific divergence with requestStorageAccess

[vsr4493]

We're seeing some differences across browsers with requestStorageAccess and storage access, and wanted to clarify if these are bugs or expected behaviours:

1. Currently in Safari requestStorageAccess needs be called on user-interaction for new tabs even if the user has granted access previously. This isn't the case in Firefox. The need for user-activation for requestStorageAccess for every new tab leads to poor UX especially for embedded widgets which rely on cookie access for authentication.

2. In Firefox, after granting storage access with requestStorageAccess, cookies are still partitioned for the embedded frame.

[annevk]

Safari's behavior is intentional. We want there to be a signal that the end user is interested in using the widget and we don't think that automatically transfers to subsequent visits.

[vsr4493]

Thank you for confirming! While I believe this introduces prompt fatigue for users and the trade-off here hurts UX I understand that this is a browser specific decision. Closing this, will follow up separately for my doubt related to Firefox.

[johnwilander]

There will not be prompt fatigue since once the user opts in, the browser remembers that. Subsequent grants only requires a user gesture in the iframe, no prompts. If you test this, it’s easy to see. Please file a WebKit bug if it’s not working as expected. It’s always better to test than to make theoretical predictions.

[vsr4493]

Subsequent grants only requires a user gesture in the iframe, no prompts

Apologies for the phrasing there, what I meant was we'd still require a user gesture to request storage access even if we have been granted access recently. The initial post above outlines this as well. This isn't equivalent to a browser prompt, but has a UX impact nevertheless for embedded widgets.

While the browser wouldn't prompt on calling requestStorageAccess, due to the gesture requirement we would still need to show a placeholder UI for the user to interact with before we can show the actual authenticated UI.

This puts pressure on the UX since the user has to do this on every new tab to use the embedded widget.