Google Chrome’s Portals: like iframes, but better, and worse.
Google just released support for Portals in Chrome Canary:
If you’re interested in cross-domain components, cross-domain communication and cross-domain web experiences, this is exciting news. At PayPal, we’ve been cultivating our suite of cross-domain libraries. The most notable of these is Zoid, which powers our embeddable payment buttons and our checkout experience.
Portals introduce a powerful new set of capabilities into this mix. Now it’s possible to build something that feels like an iframe, that can seamlessly animate and morph and take over the full browser window. Take a look at the demo video:
This is incredibly neat. Transitioning from one web experience to another on a totally different page or domain has always been a jarring experience, and portals go a long way towards solving that problem.
What about iframes?
The Chrome team explains that promotable iframes were considered for this job, but passed over. I would argue that’s a mistake; especially if the main reason is implementation effort.
Iframes are simultaneously both terrible and awesome; they’re a product of the 90s web, but they can be used to do some really awesome things:
- Embed an entire third-party experience seamlessly on a page
- Render privileged data that is protected and sandboxed from the parent page
- Communicate and share data and events in real-time with the parent page
When we built Zoid, our objective was to take these capabilities and build a way to easily and seamlessly use iframes as first-class components. These components—just like components in React — can accept props and callbacks, and trivially pass data and control back and forth between the child component and the parent.
What changes with Portals?
Portals make transitioning to a new page far smoother, using an iframe-like mechanism. But they also take away a lot of the features that make iframes great:
- You can’t interact with the embedded page until it’s been fully activated, and taken over the parent page
- Once the new page is activated, the old page apparently ceases to be able to run any code, or communicate with the new portal page
- Once the portal page has served its purpose, there doesn’t seem to be a way to close it and return control to the parent, without redirecting back or using another portal.
Quick note: the above observations are just from playing around with portals in the latest Canary build for a short time. If I’m wrong about any of this, or these features are planned, I’ll be happy to edit this! Here’s an open discussion on the topic: https://github.com/WICG/portals/issues/113
So why not just stick to iframes?
If portals were built out as an extension to iframes, they would have the potential to solve one huge problem for iframe based components: the URL bar.
In existing browsers, whenever an iframe is embedded on a page, there’s no good way for a user to verify they’re interacting with a different site without opening up the dev tools and inspecting the frame — which is not even an option on a mobile device.
That means the moment you need a user to enter any privileged information on your site, like login credentials, they have no easy way to verify that they’re not being phished. At PayPal, we solve that problem by breaking out from our iframe into a popup window, where the user can see the url bar and verify they’re on our site before they log in.
Portals, on the other hand, have the potential to make this a much more seamless experience, providing protection against potential phishing attacks by changing the url bar without forcing the user to break into into an entirely new popup window or tab.
So I’m really hoping Portals can begin to carry over some of the really important features of iframes that we use to build components. I’d love to add portal support in Zoid, and start using them as fully-fledged cross-domain components — rather than just as a mechanism for doing page transitions. Here’s hoping they become an evolution of iframes, rather than the solution to just a single problem.
—
Daniel Brain, PayPal Checkout team
