Reusing browsing context groups across navigations and traversals

[jakearchibald]

In this post I refer to isolated browsing context groups, meaning groups that have a cross-origin isolation mode that is not "none".

A top-level traversable is a browser tab/window. A top level traversable changes its session when navigated outside of web contents, eg manual location bar entry (discussed in #6356 (comment)).

I'm trying to figure out how browsing context groups are intended to be used across top level navigations and traversals as part of #6315.

My naive model is to reuse top-level browsing context groups as much as possible, so:

1. If an isolated top-level context is required, return the isolated top-level context for this combination of traversable, session, origin.
2. Otherwise, return the non-isolated context for this combination of traversable, session.

…perhaps allowing browsing contexts to be GC'd if all their associated documents are discarded, and groups to be discarded when they're empty.

However, I think we might intend on using more contexts that, but I'm not sure when/where.

In case it helps, here are some specific questions, although a general rule would be better:

---

If I navigate from:

1. //origin1/a (isolated).
2. //origin1/b (isolated).

By "isolated" I mean the document requires an isolated browsing context group. Also, assume all navigations are performed in web content, so there's no session change.

Question 1: Do 1 and 2 have the same browsing context? Pretty sure the answer is 'yes', but it's worth checking 😄 . Also, I'm assuming that a top-level cannot change browsing context without also changing browsing context group, and that a browsing context can only exist in one group.

Question 2: If both of those history entries' documents are discarded, and brought back to life via traversal, and both still require isolation, do they still share a browsing context? Hopefully this doesn't depend on the order they're visited, or whether a different history entry is visited in between.

Question 3: If yes, would it be the same browsing context as they used previously?

If I navigate from:

1. //origin1/a (not-isolated).
2. //origin1/b (isolated).
3. //origin1/c (not-isolated).
4. //origin1/d (isolated).

Question 4: Do 1 and 3 use the same bc?
Question 5: Do 2 and 4 use the same bc?

If I navigate from:

1. //origin1/a (isolated).
2. //origin2/a (isolated).
3. //origin1/b (isolated).
4. //origin2/b (isolated).

Question 6: Do 1 and 3 use the same bc?

If I navigate from:

1. //origin1/a (isolated).
2. //origin1/b (isolated).

Question 7: If I hit reload, and the page requires isolation, do 1 and 2 use the same bc?
Question 8: If I hit reload, and the page does not require isolation, then I hit reload again and the page requires isolation, do 1 and 2 use the same bc?

If I navigate from:

1. //origin1/a (isolated)
2. //origin1/b but it causes an error page due to network failure.

Question 9: Does the error page use the same bc as 1?
Question 10: If I hit reload and 2 successfully loads, and requires isolation, do 1 and 2 use the same bc?

[jakearchibald]

cc @ArthurSonzogni @camillelamy - I think you'll know the answers here.

[annevk]

I tried to take a stab at this giving answers that match how we originally envisioned this. The basic idea is that whether to swap (which always results in the creation of a new tlbc and bcg) is the result of navigating/traversing toward a resource for which there's not a COOP match. So a tlbc and bcg are only reused when there's a match.

2. If there is a different entry in between for which there is not a COOP match I would expect a swap.
3. If there has been a swap, no.
4. No.
5. No.
6. No.
7. Yes.
8. No (traversing back to 1 would reuse it, but in terms of identity it's a new tlbc/bcg).
9. No.
10. No, same as 8.

The main side effect is that links to auxiliary browsing contexts end up being broken. I think this is a positive as auxiliary browsing contexts have all kinds of flaws, but I'll admit it's a bit wonky.

[jakearchibald]

Hm yeah, it seems wonky that the behaviour a developer gets depends on bfcache and the order of traversal. But, if it's already been decided that's ok, I'll spec it 😄

[annevk]

There's further discussion, to be clear, e.g., #5350. I'm not sure I'd call this decided and changes could be made.