1 of 24

Portals

BlinkOn Toronto

April 9th 2019

Lucas Furukawa Gadani

lfg@chromium.org

2 of 24

Background

3 of 24

W3C TAG Recommendation

4 of 24

AMP

5 of 24

What are we trying to solve

6 of 24

The AMP top stories carousel

7 of 24

Other use cases considered

  • Multi-page-app to single-page-app conversion
  • Publication with infinite list of articles
  • Modal windows with origin attribution (e.g. payment processor)

8 of 24

Requirements

  • Preloading/Prerendering
  • Instant transitions -- back and forward
  • Preserving origin attribution

9 of 24

More Requirements

  • No sync DOM access
  • Not part of frame tree
  • Communication only via postMessage

10 of 24

Portals

11 of 24

<portal> element

  • Similar to <iframe>, <portal> allows content to be embedded.
  • The <portal> browsing context is not part of the same unit of related browsing contexts as its host.
  • No access to the <portal>’s WindowProxy.
  • The user-agent is free to use a separate event loop for the <portal> content (separate threads, separate processes).

12 of 24

Transitions

  • <portal>.activate() transitions instantly to the embedded content
  • Since the <portal> element provides an embedding of the page, CSS can be used to animate a transition to the portal

13 of 24

Communication

  • window.PortalHost exposed in the embedded page
  • <portal>.postMessage() and PortalHost.postMessage() can be used for communication

14 of 24

Example (video)

https://uskay-portals-demo.glitch.me/

15 of 24

Portals architecture

16 of 24

Leveraging out-of-process iframes

  • HTMLPortalElement inherits from HTMLFrameOwnerElement
  • Portal’s embedding made possible by using RemoteFrames and RemoteFrameViews

17 of 24

Status

18 of 24

Standards status

19 of 24

Implementation status

  • <portal> element able to load and render the embedded content
  • <portal>.activate() able to activate the portal, initiating the transition, as well as pass an optional data to the PortalActivateEvent
  • window.onportalactivate event fired and able to adopt the predecessor portal.
  • <portal>.postMessage working
  • PortalHost.postMessage work-in-progress
  • Partial devtools support

20 of 24

Future work

  • History model
  • Input/gestures handoff
  • CSP/XFO integration
  • Storage access model
  • Finish devtools integration

21 of 24

How to experiment

22 of 24

How to experiment

  • --enable-features=Portals

23 of 24

Questions

24 of 24

Why not extend <iframe>

  • The browser has many assumptions about the frame tree hierarchy, and in many ways it is assumed to be immutable -- which is why we proposed portals as not being part of the frame tree
  • By not exposing the Document or the WindowProxy, we allow the browser to use different threads or processes to host the portal content