Re: [w3ctag/design-reviews] Portals (#331)

@othermaciej As I understand it, Safari's model allows for certain interactions (like a user gesture, conditionally paired with a user prompt) to change the UA's answer as to whether storage access should be granted to content which was loaded in a third-party context, and an API for authors to indicate that the document is prepared for a change in its storage access.

Portal activation is conceptually similar to navigating the browsing context (possibly cross-origin), and as I understand it Safari's model does grant storage access to the document that is navigated to. Given that, would something like this work (deferring the actual access change until the document requests it)?

```js
onload = async function() {
  const supportsStorageAccessApi = !!document.hasStorageAccess;
  const canPersonalize = !supportsStorageAccessApi || await document.hasStorageAccess();
  if (canPersonalize)
    populateWithPersonalizedContent();
  else
    populateWithGenericContent();
};

onportalactivate = async function() {
  if (hasBeenPersonalized || window.portalHost)
    return;

  // This was activated into a top-level context, so the UA can
  // reasonably approve this storage request without prompt.
  await document.requestStorageAccess();
  populateWithPersonalizedContent();
};
```

There's a more uncommon case in which a nested portal is promoted into a context which is first-party to the top-level context (A->B->A becomes A->A) where it might be useful for the author to be able to request storage access but accept a silent refusal instead of triggering a user prompt, but I don't see that case being common at all.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/331#issuecomment-463238227