Confirm page isn't shown after new assignment if the page is loaded in another container already

[stoically]

Under certain circumstances it can happen that the confirm page isn't triggered despite being assigned.

Steps to reproduce

• Open tab in "Personal" container, visit example.com
• Open tab in "Work" container, visit example.com and assign to "Always open in"
• Now reload example.com in "Personal" container

Actual behavior

example.com can load in "Personal" container without interruption

Expected behavior

Confirm page to open example.com in "Work" container should be shown

Notes

Now opening a new tab and navigating to example.com opens the confirm page as expected. I realize that this an edge-case and might very well be intended behavior because example.com already successfully loaded in the "Personal" container before being assigned and this is probably related to the logic that enables "choosing between containers", however I thought I bring it up since it might maybe possible to remember if we saw a confirm page if assigned and so in this case show the confirm page, because it didn't got shown yet for "example.com in Personal"

[jonathanKingston]

The current behaviour as I understand it is that we "exempt" tabs that are already open. However we might want to readdress what we want to do here.

So one suggestion is that we could warn the user with a prompt about currently open tabs that they need to clear out data etc.

This exemption might be confusing anyway given that on shutdown of the browser these exemptions won't remain on session restore.

[stoically]

The current behaviour as I understand it is that we "exempt" tabs that are already open.

Ah, didn't know that, so it's indeed intended behavior.

So one suggestion is that we could warn the user with a prompt about currently open tabs that they need to clear out data etc.

Communicating a warning could be not that easy to explain - especially since there's (currently) no way to switch an existing tab to another container. Also I'd say that the confirm page itself would be a warning in itself if an user starts to navigate in already open tabs.

This exemption might be confusing anyway given that on shutdown of the browser these exemptions won't remain on session restore.

Yeah, would probably make sense to design the behavior consistent, in the one way or the other.

Personally I'm in favor to take the click on "Always open in" seriously and from that moment on show the confirm page, regardless of open tabs.

[jonathanKingston]

Also I'd say that the confirm page itself would be a warning in itself if an user starts to navigate in already open tabs.

To my knowledge the exemption ignores navigations in tabs that are exempted. So they won't get a warning there.

Personally I'm in favor to take the click on "Always open in" seriously and from that moment on show the confirm page, regardless of open tabs.

People didn't like this equally, I forget the bug that this was resolved in. The exemption wasn't in the first release of assignment. I think the biggest rationale is that users couldn't ever get back to delete those cookies in the exempted tabs.
Closing all the tabs would be too aggressive too.

[stoically]

To my knowledge the exemption ignores navigations in tabs that are exempted. So they won't get a warning there.

Yeah, I meant if the exemption would get removed, then the confirm page could serve as a warning

I think the biggest rationale is that users couldn't ever get back to delete those cookies in the exempted tabs.
Closing all the tabs would be too aggressive too.

Navigating in exempted tabs after assignment opens a new tab, so the old tab stays open and its possible to instruct cookie-cleaners to remove cookies there. So as long as tabs aren't closed, that should be no problem. Also, you get to choose which container you want to continue in, and you can choose the "old" container and with that have a tab with the old cookies back.

People didn't like this equally, I forget the bug that this was resolved in.

The only Issues I was able to find regarding this are #626 and #635, but those are only related and are not the reason for the implementation.

However, I just wanted to bring it up because it was unexpected to me and I couldn't find an Issue about it (especially since I didn't know about "exemption"), so I would be equally fine with just leaving it as it is.