Intent to Implement: Portals

[Lucas Gadani]

Intent to Implement: Portals

Contact emails

jbr...@chromium.org, kenji...@chromium.org, l...@chromium.org, rby...@chromium.org

Explainer

https://github.com/KenjiBaheux/portals/blob/master/explainer.md

Design doc/Spec

Design doc: https://docs.google.com/document/d/1ITizGVUmfFGktOOynHFhx87cnJ__7EXy-4uMpOE0OAg/edit?usp=sharing

Summary

The goal of portals is to provide a way to enable seamless navigations between pages.

Motivation

One of the main concerns regarding the web platform is that web pages can be slow to load. With Portals, we aim to provide web developers with a powerful tool to enable seamless navigation transitions between pages and between embedded and non-embedded states.

We hope that this feature would enable web developers to provide great user experiences with fast transitions on cooperating sites, while addressing concerns that have been raised by the community [1] [2].

[1] https://discourse.wicg.io/t/proposal-for-promotable-iframe/2375

[2] https://www.w3.org/2001/tag/doc/distributed-content/

Risks

Interoperability and Compatibility

Edge: No signals

Firefox: No signals

Safari: No signals

Web developers: No signals

Ergonomics

Are there any other platform APIs this feature will frequently be used in tandem with?

This API could be used in tandem with Signed HTTP Exchanges in order to provide even faster page loading and transitions, though it could also be used on its own.

Could the default usage of this API make it hard for Chrome to maintain good performance (i.e. synchronous return, must run on a certain thread, guaranteed return timing)?

Our aim is to keep resource usage similar to what iframes require today. Unlike previous attempts at prerendering, we also expect that the default usage of portals would be in places where iframes are currently used, and therefore we don’t expect a significant increase in resource consumption

Activation

Will it be challenging for developers to take advantage of this feature immediately, as-is?

Developers should be able to start using the feature right away.

Would this feature benefit from having polyfills, significant documentation and outreach, and/or libraries built on top of it to make it easier to use?

Yes, we expect that framework and/or library authors to take advantage of portals by providing simple ways of coordinating smooth transitions between pages.

Debuggability

Portals should be available via the standard chrome://inspect interface. Initially, this would allow independent debugging of both the portal and it’s owner. In the future we’d like to support debugging both pages from a single devtools instance, similar to iframes.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

Link to entry on the feature dashboard

https://www.chromestatus.com/feature/4828882419056640

Requesting approval to ship?

No.

[Lucas Gadani]

A new <portal> HTML tag, as explained here: https://github.com/KenjiBaheux/portals/blob/master/explainer.md

On Fri, Jul 20, 2018 at 2:02 PM Rik Cabanier <caba...@gmail.com> wrote:

Are you proposing to add a new <portal> HTML element or is it adding new behavior to iframe?

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEgCuoFCjJhHW9RowBCrzrd8sfBKUNK8bJgf8A0nCnJKjycudw%40mail.gmail.com.

[Boris Zbarsky]

On 7/20/18 2:12 PM, Lucas Gadani wrote:
> A new <portal> HTML tag, as explained here:
> https://github.com/KenjiBaheux/portals/blob/master/explainer.md

The explainer mentions that iframe promotion had all sorts of problems,
but doesn't make it clear why this proposal is easier to implement or
simpler than iframe promotion. Is there an existing explanation somewhere?

-Boris

[Lucas Gadani]

Security is the main reason we went with an alternative proposal to iframe promotion. In particular, since permissions propagate down the frame tree, we think that a feature that could allow reparenting of an iframe could become a source of security bugs, as has happened in the past with magic iframes.

With portals, our idea is to treat each portal as their own top-level browsing context, with their own set of permissions. We also want to restrict communication between portals and their owning document to only postMessage (no access to the WindowProxy), which wouldn't be possible if we were using iframes.

[Boris Zbarsky]

On 7/20/18 2:58 PM, Lucas Gadani wrote:
> With portals, our idea is to treat each portal as their own top-level
> browsing context, with their own set of permissions. We also want to
> restrict communication between portals and their owning document to only
> postMessage (no access to the WindowProxy), which wouldn't be possible
> if we were using iframes.

This could all be done with an iframe with an attribute on it, right?

I guess a new tag name might make sense if the API is really quite
different from the one HTMLIFrameElement exposes.

That said, adding a new tag has its own compat risks. What is the
proposed parsing behavior for <portal>? Is it more like <span> or more
like <iframe> or something else?

-Boris

[Lucas Gadani]

On Fri, Jul 20, 2018 at 3:03 PM Boris Zbarsky <bzba...@mit.edu> wrote:

On 7/20/18 2:58 PM, Lucas Gadani wrote:
> With portals, our idea is to treat each portal as their own top-level
> browsing context, with their own set of permissions. We also want to
> restrict communication between portals and their owning document to only
> postMessage (no access to the WindowProxy), which wouldn't be possible
> if we were using iframes.

This could all be done with an iframe with an attribute on it, right?

That is true, but developer's may find it frustrating that a lot of their expectations regarding iframes would change with the presence of this attribute.

I guess a new tag name might make sense if the API is really quite
different from the one HTMLIFrameElement exposes.

Exactly. 

That said, adding a new tag has its own compat risks.  What is the
proposed parsing behavior for <portal>?  Is it more like <span> or more
like <iframe> or something else?

This isn't something I put a lot of thought into, but ideally I think I'd prefer to not special case the parser, so I'd prefer something more like a <span> tag, but could you elaborate a bit more what are your concerns when it comes to parsing?

[Boris Zbarsky]

On 7/20/18 3:35 PM, Lucas Gadani wrote:
> This isn't something I put a lot of thought into, but ideally I think
> I'd prefer to not special case the parser, so I'd prefer something more
> like a <span> tag, but could you elaborate a bit more what are your
> concerns when it comes to parsing?

There are two main concerns that need to be considered here:

1) How does fallback work for browsers that don't implement the
<portal> tag?

2) Changing the parsing algorithm is generally not desirable.

-Boris

[Lucas Gadani]

On Fri, Jul 20, 2018 at 3:47 PM Boris Zbarsky <bzba...@mit.edu> wrote:

There are two main concerns that need to be considered here:

1)  How does fallback work for browsers that don't implement the
<portal> tag?

2)  Changing the parsing algorithm is generally not desirable.

That makes sense. In this case, I believe that by not special-casing the <portal> tag, we'd allow fallback content to render it under browsers that don't implement the feature, as well as not having to change the parsing algorithm.

[Boris Zbarsky]

On 7/20/18 4:02 PM, Lucas Gadani wrote:
> That makes sense. In this case, I believe that by not special-casing the
> <portal> tag, we'd allow fallback content to render it under browsers
> that don't implement the feature, as well as not having to change the
> parsing algorithm.

It's a bit complicated. If the fallback is an iframe, then should that
load? If it's parsed as an actual <iframe> and there are no changes to
the processing model in the spec, then it would, even in a browser that
supports <portal>.

My main point is that the fallback behavior should be thought about
pretty carefully if the parser is not changing.

-Boris

[Rik Cabanier]

Are you proposing to add a new <portal> HTML element or is it adding new behavior to iframe?

On Fri, Jul 20, 2018 at 10:39 AM Lucas Gadani <l...@chromium.org> wrote:

[rhal...@google.com]

Hi Lucas,

I think this benefits from a privacy review. Could you please file a launch bug?

[dvoy...@google.com]

Lucas, so the <portal> itself is considered to be a top-level context? I.e. are X-Frame-Options/CSP frame-ancestors observed for them? If not, are there any write-up about click/input-jacking?

[Lucas Gadani]

Yes, we are proposing that portals should be top-level contexts, but they should still respect XFO/CSP rules defined for iframes.

There have been suggestions about adding a specific opt-in, for pages that don't want to be embedded in iframes but are ok being embedded in a portal, though I still don't have an opinion on whether this is desirable for the current proposal.

I strongly encourage anyone that has thoughts or suggestions to get involved in the design, by filing bugs on the github explainer.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/ccf9377d-74c2-4178-86d2-25437609cddb%40chromium.org.

[oj...@google.com]

I've been viewing the question of whether to do a new element or an attribute on iframe as an option question. I think the 2 issues Boris mentioned are the right ones for making that decision. Can we make sure to encode this in an open github issue?

Lucas Gadani wrote:

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEgCuoG2eju0bgriB_aJ%2Byb-%2BNV%2BYvfX56s7vQ%3D0EnVmGYu7kQ%40mail.gmail.com.

[Joe Pea]

The concept of cross-domain client-side routing would be super awesome in making content immersive across domains: https://discourse.wicg.io/t/single-page-app-across-multiple-domains/2943/8