Replacement navigation and about:blank

[jakearchibald]

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]

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]

@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]

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]

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]

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 #215, where we create the idea of "pop-out" portals, where navigating back to about:blank would be weird.

[domenic]

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]

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]

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]

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]

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.