1310261 - Consider severing the opener relationship on explicit navigations

Status: NEW

(Core :: DOM: Core & HTML, defect, P3)

Description

[Nika Layzell [:nika] (ni? for response)]

When the user types a URL into the addressbar, navigating to a new URL, that currently occurs within the toplevel browsing context of the current tab. This means that any other pages which have a reference to that browsing context, and the opener of that browsing context, remain linked to the new page. 

We should consider the webcompat implications and potential benefits which we could gain by making every explicit navigation through the URL bar create a distinct browsing context with a connected history.

Comment 1

[Jonathan Kingston [:jkt] he/him]

One issue that should be considered is:

1. User is on example.com and it opens paypal.com
2. User switches back to example.com tab and changes the awesomebar to google.com
3. User then presses back on google window getting them to example.com

window.opener should probably be reconnected when the user is back on example.com.

One way to solve this might be to store the opener in the history and reconnect when the user is back on that page.

Comment 2

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Hi Nika,
My team is revisiting some old bugs and we come across this. We are not quite sure if this issue still valid, especially after Fission. Quick thoughts?

Comment 3

[Nika Layzell [:nika] (ni? for response)]

To my understanding we haven't made any changes with regards to this behaviour, so the suggestion is still valid. This change would involve treating navigations which were triggered by the user through the URL bar (and which aren't to URIs like javascript:) as-if they they are bcg-switching loads to sever these opener relationships.

Actually getting window.opener to reconnect as suggested in comment 1 is probably more complex, and it's unclear how much we would benefit.