Prerendering and opening links in new windows

[jakearchibald]

An aggregator like Reddit/Google Search could use portals to prerender content for quick access. However, in the current design, if I open a link in a new tab the prerender isn't used. So, as a user I've paid the bandwidth cost, but get none of the benefit.

If prerendering is a primary use-case, are we missing something fundamental?

[jeremyroman]

There's nothing that fundamentally prevents us from opening the prerendered page in a new window, I think; we just don't have APIs for it.

[jakearchibald]

It'd be good to figure out a rough idea of how to do that, just to reduce the change that we accidentally do something that prevents it later.

But if it's the main pitch of portals, it feels like we should do something about it sooner.

[domenic]

It seems this could be partially solved by #174. If the default click behavior for portals is to activate them, then the default middle-click behavior for portals could be to activate them into a new window. Similarly for the default right-click-open-in-new-window-menu-item behavior.

That is, if we introduce the concept that users can trigger a portal activation without page author code getting in the way via #174, it seems like it would be pretty easily extensible to activate-into-new-window.

---

Separately, this could just be something like .activate({ newWindow: true }), I think.

[jeremyroman]

@lucasgadani fyi

+1 to @domenic's general comments above. I would note that from Chromium's implementation details moving a portal contents into a new window may become trickier as we move away from a single content::WebContents. We should definitely not foreclose this, but that may make Chromium as an implementer less likely to support this early on.

[jakearchibald]

@domenic

if we introduce the concept that users can trigger a portal activation without page author code getting in the way via #174, it seems like it would be pretty easily extensible to activate-into-new-window.

Maybe. Although, it's tricky in cases where the user doesn't click on the portal itself, eg a link on Google search.

Separately, this could just be something like .activate({ newWindow: true }), I think.

This misses things that are browser specific, like middle-click's "open in background tab", and the recent tab-grouping stuff in Canary.

[jakearchibald]

Possible solutions off the top of my head:

---

Some form of navigate event, where the developer can provide a portal to use for the navigation. Previously I've pitched the navigate event as something that only happens on navigations where the user hasn't provided a preference on how the navigation should happen, but that isn't the case here.

---

Something like <portal prerender>, which tells the browser "hey, if a navigation happens from this page to the same URL in the portal, use the document in the portal.

I guess we'd also need to fire an event on the portal to indicate that the inner document is now gone.

[jeremyroman]

Yeah, I've been thinking along similar lines. Between the two I think I'd prefer the latter, and I think it aligns reasonably well with viewing a <link rel=...> trigger as a portal that is not rendered in the document but which has the "you can use me to satisfy a navigation originating in this document" flag set.