search

WICG / portals

A proposal for enabling seamless navigations between sites or pages
https://wicg.github.io/portals/
Other
947 stars 66 forks source link

portalactivate custom/default action for successor page #163

Closed rinodrummer closed 4 years ago

rinodrummer commented 5 years ago

Using portals with external website (for test purpose) I got stack in the successor page because (obviously) there was no portalactivate event listeners.

May we be able to make a custom portalactivate handler that can control how we want to interact with the successor page? Or will a default action for this event be supplied?

If not, can an HTML property be specified to make sure that the user can navigate back to the predecessor page using the history controls?

jeremyroman commented 4 years ago

It is intended that you be able to navigate back; that you couldn't was a bug in the Chromium implementation.

Though the spec wording of this hasn't landed yet, the latest Chrome Canary should have better behavior in this regard. @kjmcnee anything else to add here?

rinodrummer commented 4 years ago

Oh, thanks @jeremyroman!

So, just to add details, I'm using Google Chrome 78.0.3904.108.

kjmcnee commented 4 years ago

Right, the history controls not working across a portal activation was an issue fixed in chromium version 80.0.3980.0. The browser will treat the portal activation like a regular navigation in terms of how it affects session history. So there will be no need to adopt the predecessor just to make session history work.

juliadou commented 4 years ago

I just downloaded chrome unstable version 80.0.3983.2 on linux. The page crashes whenever portal is appended to the DOM.

jeremyroman commented 4 years ago

Please report Chromium implementation bugs (with a reproduction case, if possible) on crbug.com/new. Thanks. :)

domenic commented 4 years ago

Since this seems to mostly be about Chromium issues, I'll close it, since those are tracked on crbug.com. If I misunderstood, let me know and we can reopen.