Interacting with a non-activated portal?

[bluepnume]

Is there a way to build a portal such that:

• a) As a user, I can interact with it before takes over the full window (or is 'activated')
• b) I can message between the portal and the parent window, as it's being interacted with
• c) I can have it take over the url bar while it's being used, but before it takes over the window

I maintain https://github.com/krakenjs/zoid which we use at PayPal for delivering cross-domain components for our experiences (like buttons and checkout flows) inside iframes.

I'd love to extend support for portals if they're a good fit, but from a little experimenting it seems like you can only interact with them after they've been activated, and after that point the parent window is lost. That makes it tricky to think about using portals as components.

c) would also help solve a huge problem we have around giving users a way to ensure they're interacting with a frame that is owned and controlled by our domain, to avoid the potential for phishing attacks.

[oliverdunk]

I'm also new to this codebase, but here's my understanding:

• a) This isn't possible. I'm not certain where the spec defines this, but I assume it is implied by the fact that the host "embeds its rendered output", instead of nesting it.
• b) Interaction isn't possible per a), but communication is possible. You can use window.portalHost.postMessage from the portal to the host, and postMessage on the portal element for communication in the other direction.
• c) Assuming we stick with zero interaction, I assume you wouldn't want this anymore. If interaction was added, it's an interesting idea. I think what would really be needed to solve your problem would be a new URL bar, as changing the existing one would make users even more confused?

[oliverdunk]

Something to add - there's support for the activated portal to activate the host again at a later time. Not certain how that would help you but it seems like something you might find interesting. For an example of how that could work for a popup, see https://www.youtube.com/watch?v=4JkipxFVE9k

[jeremyroman]

Is there a way to build a portal such that:

• a) As a user, I can interact with it before takes over the full window (or is 'activated')

Presently, no. We are interested in adding support for both no-input (for "preview-like" use cases) and input (for "widget-like" use cases) modes, but for the time being we're starting with the former.

• b) I can message between the portal and the parent window, as it's being interacted with

When page A is active, it can use postMessage on the HTMLPortalElement to send messages to B (which it receives on the window.portalHost object). When you activate (and call adoptPredecessor), these pages change roles, so the page B (which was previously embedded) can communicate with page A by posting messages to the portal in which it adopted A.

• c) I can have it take over the url bar while it's being used, but before it takes over the window

This becomes tricky, because we need to ensure that the URL that the user sees in the browser chrome corresponds to the content which is displayed in the window content area, so that the user has a clear idea of how the URL seen in the browser chrome corresponds to the content.

One could imagine paypal.com embedding the original content (with suitable cooperation between the two origins, appropriate lightbox or similar UI to reduce phishing risk etc) as a portal while the PayPal page does fill the window.

This sort of use case might benefit from more specific browser support (some kind of "modal activation" where the browser takes care of shading the original page, or something like that). It might be worth looking into in more detail if authors like you think it would be helpful.

I maintain https://github.com/krakenjs/zoid which we use at PayPal for delivering cross-domain components for our experiences (like buttons and checkout flows) inside iframes.

I'd love to extend support for portals if they're a good fit, but from a little experimenting it seems like you can only interact with them after they've been activated, and after that point the parent window is lost. That makes it tricky to think about using portals as components.

c) would also help solve a huge problem we have around giving users a way to ensure they're interacting with a frame that is owned and controlled by our domain, to avoid the potential for phishing attacks.

It's good to hear that you're interested in how portals can help make origin attribution clearer for users.

[nathanheffley]

Something I've noticed while experimenting with portals is that it is possible to interact with a portal at least on initial page load. For example, if you embed https://www.google.com as a portal, the search box gets focused automatically on page load. It's possible to type and hit enter to search. You can also use tab to select different elements inside of the embedded portal.

[Velenir]

Something I've noticed while experimenting with portals is that it is possible to interact with a portal at least on initial page load. For example, if you embed https://www.google.com as a portal, the search box gets focused automatically on page load. It's possible to type and hit enter to search. You can also use tab to select different elements inside of the embedded portal.

This has also been my experience. As long as the page inside the portal has autofocus it starts capturing keyboard events, but not mouse events.

[jeremyroman]

Something I've noticed while experimenting with portals is that it is possible to interact with a portal at least on initial page load. For example, if you embed https://www.google.com as a portal, the search box gets focused automatically on page load. It's possible to type and hit enter to search. You can also use tab to select different elements inside of the embedded portal.

This has also been my experience. As long as the page inside the portal has autofocus it starts capturing keyboard events, but not mouse events.

This sounds like a bug in the Chromium implementation (rather than a spec bug). @a4sriniv, do we have a crbug filed for that?

[westonruter]

Bringing in a conversation from Twitter…

The lack of support for user interactivity in the portal seems like a downside versus iframes. In the Portals Embed Demo it shows the user being able to play the video and then later activate the portal. @uskay pointed out this interactivity is actually due to the portalHost sending messages which the window in the portal listens to in order to cause the video to play. However, requiring a portal host to send message to perform every user interaction in the portal seems like a big burden versus what iframes provide. Some interactions would be difficult or impossible to simulate in a window via the DOM.

The use case I had in mind for portals was a paired browsing UI which shows the AMP and non-AMP versions of a page presented side-by-side to check for visual and functional parity. We have this implemented using iframes currently (see YouTube video below):

From this paired browsing demo using iframes, you can see there is an undesirable white flash when entering and exiting the UI as the pages reload. Using portals would would allow one window to persist. But the portals would need to be fully interactive, so the user can scroll, open the nav menu, play 3rd-party embeds, and generally do anything they'd normally do while navigating around a site. Cannot portals more closely behave like iframes in this way? I suppose what I'm asking for is the “widget-like” use case referred to by @jeremyroman above in https://github.com/WICG/portals/issues/113#issuecomment-490917366.

[jeremyroman]

That's a cool idea.

I think it would be great to allow something like this. Most of the use cases we looked at benefited from preventing input, but we think that it would be useful to add an option to restore input/focus/etc. (Especially there are some cases where it could enable further click-jacking and similar attacks, which require more work to mitigate.)

Unfortunately I think it's not likely to be in the first version of this feature implemented in Chromium, but as evidenced by this issue and your scenario, this is something that will probably be worth following up on.