search

WICG / portals

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

Replacement navigation and about:blank #214

Closed jakearchibald closed 4 years ago

jakearchibald commented 4 years ago

From https://html.spec.whatwg.org/multipage/history.html#location-object-navigate:

If … the browsing context's session history contains only one Document, and that was the about:blank Document created when the browsing context was created, then the navigation must be done with replacement enabled.

Should we do the same with portals?

This covers the case where window.open is called, and a portal is created (or moved?) within the new window, and activated. Should that be a new session entry?

I'm leaning towards "replace" to avoid a new session entry. This seems consistent, and paves the way for creating pop-out portals.

jakearchibald commented 4 years ago

Although I use "consistency" as an argument here, I don't think we should do a replacement navigation if the portal is activated before document load, which is different to how location.href works.

But the use-case there seems to be JS "redirects", and I don't think it makes sense to use portals for that.

jeremyroman commented 4 years ago

@kjmcnee because history

This seems to me like a special case that was added basically because a browsing context always comes with an about:blank document before you navigate, but you probably don't want that in the history.

I'm less convinced this argument applies to portal activation (why wouldn't you just navigate ordinarily? the existing document is presumably blank so why keep that rendered instead of the navigation destination?), but honestly I would expect this to happen ~never so I don't know that I feel strongly.

jakearchibald commented 4 years ago

I'm mostly thinking of future cases where it might be possible to move a portal to a newly-created window and activate it. But there's a lot of stuff to solve before we get there.

Maybe we'll be able to change behaviour later? But I'm a little worried it'll be a web compat issue by then.

domenic commented 4 years ago

I don't quite understand the OP here. What is the proposal?

I very much like how portals do not have the horrible complexity that comes with the initial about:blank with popups and iframes. This is a big feature of portals. I hope we never have special initial about:blank and its corresponding history/Document/Window complications.

jakearchibald commented 4 years ago

The pattern is:

  1. Open new about:blank window.
  2. Create portal in that window.
  3. Activate that portal.

Can the user now click back to go to about:blank?

This might be a little related to https://github.com/WICG/portals/issues/215, where we create the idea of "pop-out" portals, where navigating back to about:blank would be weird.

domenic commented 4 years ago

Oh, very interesting. So this is about history in the host browsing context, and how activation affects it. The guest browsing context stays nice and simple and clean.

In that case I am less concerned with which we choose. I guess reducing the number of cases of "replacement enabled" seems slightly simpler, but if there were a real use case where it might matter, we could do it. I currently agree with Jeremy that this seems very unlikely to happen in practice, which makes me inclined toward more simplicity, but I can see how #215 might impact that.

kjmcnee commented 4 years ago

about:blank cannot host a portal (https://wicg.github.io/portals/#htmlportalelement-may-have-a-guest-browsing-context), so this shouldn't be possible. I think we'll want an option for the activate method to enable replacement to offer the same capability as location object navigation, but we don't have to worry about special casing about:blank.

jakearchibald commented 4 years ago

Interesting! Why is about:blank not allowed to host a portal?

Actually, there might be a privacy issue here. If a portal can be put in a JS-controlled window, then data can be transferred via the resize events. Excluding about:blank doesn't prevent that.

jakearchibald commented 4 years ago

Interesting! Why is about:blank not allowed to host a portal?

Ah, I see, because it could adopt about:blank once it's activated. Although, I think new windows inherit their origin from the parent, so you could probably work around this. Anyway, the privacy issue is more important.

domenic commented 4 years ago

The privacy issue is tracked in #216. The fact that about:blank cannot host a portal is tested in web platform tests. I think this issue is closable, but it's a bit meandering, so please reopen or comment if I'm wrong.