Document reasons why portal activation can fail

[jeremyroman]

Currently the following cases exist in the Chromium implementation. Those marked with an asterisk (*) are already expressed in the draft:

Synchronously:

1. no browsing context associated with the element*
2. another HTMLPortalElement has an outstanding activation
3. the element is itself inside a portal browsing context*
4. activate data serialization failure*

Asynchronously:

1. a top-level navigation was in progress when the browser tried to execute the activation
2. no document was yet loaded in the portal, e.g. because the fetch isn't far enough along to commit, or because the UA chose to block it for some reason (incl. but not limited to CSP)
3. an error page (interstitial) is being displayed, rather than the requested resource

[jeremyroman]

@domenic three of the seven possible reasons are currently expressed in the draft

[jakearchibald]

a top-level navigation was in progress when the browser tried to execute the activation

Is this consistent with other forms of navigation? I thought in-process navigations were cancelled if a new navigation happens, but I'm sure it's more complicated than that.

no document was yet loaded in the portal, e.g. because the fetch isn't far enough along to commit, or because the UA chose to block it for some reason (incl. but not limited to CSP)

Do developers have a way to detect when the fetch is far enough along?

[kjmcnee]

In chromium at least, renderer initiated navigations without a user gesture are not allowed to cancel a browser initiated navigation. The idea is to prevent a page from trapping a user who is trying to use the back button by navigating repeatedly.

We have the same behaviour for portals: a portal activation without a user gesture cannot cancel a browser initiated navigation.

[jeremyroman]

a top-level navigation was in progress when the browser tried to execute the activation

Is this consistent with other forms of navigation? I thought in-process navigations were cancelled if a new navigation happens, but I'm sure it's more complicated than that.

Ultimately there's a point at which the browser has decided to go ahead with the navigation. In Chromium, at least, this is triggered by the beginning of the response body. At this point we have changed, or are about to change upon receiving a rendered frame, the page that the user is looking at. Activation cannot proceed at that point.

Navigations are cancelled by new navigations, unless they have reached this point.

no document was yet loaded in the portal, e.g. because the fetch isn't far enough along to commit, or because the UA chose to block it for some reason (incl. but not limited to CSP)

Do developers have a way to detect when the fetch is far enough along?

They have a way to detect later events, like load. I don't know whether we can reasonably expose this information. This is necessary because the entire load could end up being blocked and then we have nothing to show the user. This could have already happened, or we could be sitting waiting on a request which will ultimately result in a redirect to an invalid URL, a response with a CSP that prevents loading, or something similar.

[jakearchibald]

@kjmcnee

In chromium at least, renderer initiated navigations without a user gesture are not allowed to cancel a browser initiated navigation. The idea is to prevent a page from trapping a user who is trying to use the back button by navigating repeatedly.

We should probably spec this if it isn't already (and I don't recall seeing it).

[jakearchibald]

@jeremyroman

Do developers have a way to detect when the fetch is far enough along?

They have a way to detect later events, like load. I don't know whether we can reasonably expose this information. This is necessary because the entire load could end up being blocked and then we have nothing to show the user.

I'm unsure about this, but I don't want to derail this issue. Filed #191.