Intent to Experiment: Portals (Same-Origin, Android Only)

[Jeremy Roman]

Contact emails

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

Spec

https://wicg.github.io/portals/

We are aware that this specification is incomplete and has pending unresolved feedback. We intend to address feedback in parallel with the experiment period, in part based on feedback gathered during the experiment.

TAG review

https://github.com/w3ctag/design-reviews/issues/331

Design docs

https://docs.google.com/document/d/1ITizGVUmfFGktOOynHFhx87cnJ__7EXy-4uMpOE0OAg/edit

https://docs.google.com/document/d/1DX2pv2xBaiWb6WqNPkwrnPjhOtgdyo5Fl20iSqs_AuA/edit

Summary

Portals is a feature which enables seamless navigation between documents, by allowing a document to be loaded and embedded in a manner similar to <iframe>, but later "activated" to become the main frame. The document then has the opportunity to "adopt" the predecessor so that a seamless transition back, or amongst several portals, is possible. See the explainer and key scenarios for more info.

For this trial, authors will be restricted to only creating same-origin portals, i.e., they may only load documents which are same-origin with the host document (which must be in the main frame). This enables some use cases, such as adding more seamless transitions to a multi-page app (MPA), though not the full power that is possible with unrestricted portals, which remain behind a flag.

Link to “Intent to Prototype” blink-dev discussion

https://groups.google.com/a/chromium.org/d/topic/blink-dev/SgsbpO08AeI/discussion

Goals for experimentation

We aim to gauge developer interest for this feature, gather feedback about how well the API suits their needs, and identify partners for a subsequent trial of cross-origin portals.

We have previously gathered some feedback from developers building demos, but we need additional feedback about how these experiences work in a real world setting.

This trial will be limited to same-origin portals only, because this allows us to gather feedback from developers about how well this API addresses their use cases, before we invest more fully in the additional work required to support cross-origin portals.

Experimental timeline

Experiment begins in M84 (branch in May 2020, stable release in July 2020) 

Experiment ends in M86 (branch in August 2020, stable release in October 2020).

Any risks when the experiment finishes?

None anticipated. No special data is written to disk, and authors are expected to feature-detect the portals feature (through the presence of HTMLPortalElement) and fall back when it is not available.

Ongoing technical constraints

None anticipated.

Debuggability

Portal contents should be inspectable using the DevTools inspector. It should also be possible to select a portal’s execution context in the DevTools console selector, and execute code inside a portal’s context. The DevTools window should also stay open and refresh across portal activation (similar to regular navigation) and features like breakpoints and device emulation should work predictably across portal activation.

Will this feature be supported on all five Blink platforms supported by Origin Trials (Windows, Mac, Linux, Chrome OS, and Android)?

This experiment is limited to Android Chrome only (excluding WebView).

The feature largely works on desktop, but due to known issues with extensions we're not yet ready to support general users using portals on desktop. Developers can continue to enable portals on desktop for development purposes only.

Link to entry on the feature dashboard

https://chromestatus.com/features/4828882419056640

[sligh...@chromium.org]

LGTM

[Mike West]

On Thu, Apr 16, 2020 at 6:00 PM Jeremy Roman <jbr...@chromium.org> wrote:

Summary

Portals is a feature which enables seamless navigation between documents, by allowing a document to be loaded and embedded in a manner similar to <iframe>, but later "activated" to become the main frame. The document then has the opportunity to "adopt" the predecessor so that a seamless transition back, or amongst several portals, is possible. See the explainer and key scenarios for more info.

For this trial, authors will be restricted to only creating same-origin portals, i.e., they may only load documents which are same-origin with the host document (which must be in the main frame). This enables some use cases, such as adding more seamless transitions to a multi-page app (MPA), though not the full power that is possible with unrestricted portals, which remain behind a flag.

Locking things to same-origin documents removes several of the security and privacy concerns that have been raised elsewhere, so this experiment LGTM2 (FWIW). That said, I think we've talked about this before, but help me remember: what is the behavior if the portaled document attempts to navigate to a cross-origin page?

-mike

[Jeremy Roman]

Such a navigation is cancelled.

 

-mike

[Jeremy Roman]

On Thu, Apr 16, 2020 at 11:59 AM Jeremy Roman <jbr...@chromium.org> wrote:

Contact emails

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

Spec

https://wicg.github.io/portals/

We are aware that this specification is incomplete and has pending unresolved feedback. We intend to address feedback in parallel with the experiment period, in part based on feedback gathered during the experiment.

TAG review

https://github.com/w3ctag/design-reviews/issues/331

Design docs

https://docs.google.com/document/d/1ITizGVUmfFGktOOynHFhx87cnJ__7EXy-4uMpOE0OAg/edit

https://docs.google.com/document/d/1DX2pv2xBaiWb6WqNPkwrnPjhOtgdyo5Fl20iSqs_AuA/edit

Apologies; the second of these appears to have been created in the google.com domain instead. A publicly accessible version is available here:

https://docs.google.com/document/d/1a7dTpCtj1w17P3a5QNoSIyNvy-9iiZRy3nmjTHAFMKM/edit

[Jeremy Roman]

Update: we've been forced to push this to M85 since we do not expect to resolve our remaining blocking bugs in time for the M84 branch.