Handling fallback content for portals

[lucasgadani]

One of the issues that were brought up in the Chromium intent thread (https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/SgsbpO08AeI) was how to handle fallback content.

I haven't given this a lot of thought yet, but this is something we should consider carefully as we write the spec, since it's important to interop with browser that may not support portals.

[domenic]

I think this is pretty straightforward. The parser does nothing special with <portal>, so in browsers that don't support it, it gets treated like <asdf>, and so the contents between <portal> and </portal> show up as fallback.

In browsers that do support it, we need a bit of spec work to state that the children are hidden. This ties in to the general spec work needed to state how portals are rendered.

[domenic]

Should we display fallback content in cases where the portal fails to load, e.g. portals inside nested browsing contexts?

[kjmcnee]

By failing to load, are we talking about both eligibility of the host (e.g. no nested contexts) and conditions in the portal context (e.g. no network), or just the former?

[domenic]

Good question. I think we need to consider both. In particular, do we want portals to be able to display error pages? Or should they get closed when that would otherwise show up?

This is interesting because, e.g., for iframes, navigating to a blob URL will display an error page. We've chosen instead to close the portal, but now we have to decide where to use closing and where to use error pages.

[jeremyroman]

I admit to not being super invested in the idea of fallback content, but I would think that the simplest rule is probably that if there's no browsing context we render fallback content instead.