Should you be able to tell if a portal is currently closed, without calling activate()?

[Domenic Denicola]

There are a few important cases where a portal can be closed:

• Host page messed up, e.g. <portal src="data:text/foo,bar"></portal>.

• Portaled content is broken, e.g. it 301s to a data: URL, or it network errors.

• The user is offline (causing a network error)

In all cases, the page author will know about this when .activate() is called, as .activate() will reject.

But, should we also let the page author know about these failures beforehand? I think this is mostly important for preview experiences, where such an API would allow useful actions such as periodically retrying, displaying a custom error, or similar. #251 also plays a role here, in how such preview experiences would be put together.

[Jake Archibald]

In a doc, @kjmcnee suggested the following portal states:

• Empty - Nothing has ever been loaded in the portal, or the previous contents were discarded due to failed readoption, the user agent reclaiming resources, etc.
• Live - The portal is hosting a browsing context.
• Activated - The portal has activated. The element’s context is adopted or in bfcache.
• Frozen - The hosted context is alive, but frozen by the user agent.
• Epitaph - Like empty, but there’s a screenshot or some other visual representation of the previous content.

Portaled content is broken, e.g. it 301s to a data: URL, or it network errors.

Can we detect this currently with iframes and such, or is it a new capability?

[Jeremy Roman]

I was surprised to learn that in Chromium, at least, both of those cases today fire load rather than error. And of course this will permit loads that might not be possible in an iframe or might be partitioned in some browsers. This could potentially be a coordination risk (e.g., slowly sharing a user identifier) if the origin had credentials.

Since it doesn't, though, this looks a lot like what you could learn from a no-cors fetch, which does report both unsafe redirects and network errors as a "TypeError: Failed to fetch", in addition to lack of CORS preflight (which seems analogous to lack of an uncredentialed prerendering opt-in).

So . . . I suspect we are okay here, but could be overlooking something.

[Kevin McNee]

Indeed, it seems reasonable to simply expose the element lifecycle state as described above. The only interesting bit of information is whether the portal is in the empty state or not. As jeremyroman mentions, I suspect this is not meaningfully different than what could be communicated by fetch failing. The UA's ability to discard arbitrarily would presumably add to the uncertainty of what this bit could actually communicate to the portal host.