Spec changes for browsing context group change on cross-site + same-site navigations

[Rakina Zata Amni]

Hi Anne (and people I cc'd),

I am currently working on some changes in Chrome that will result in more browsing context group changes on cross-site and same-site top-level navigations that meet some criterias (the previous page doesn't currently have any opener relationship, etc). This means scripting relationships will be carried over after navigation less often, leading to cases like the one mentioned in crbug.com/1043162. You mentioned this behavior is OK, but we need some spec changes to make sure the behavior is clear to everyone, because the current spec only does browsing context changes implicitly.

I'm curious about which parts need to change. It seems like we might be able to follow the spec changes for COOP and modify the "obtain a browsing context to use for a navigation response" steps? There's also the "rules for choosing a browsing context" but I'm not sure how that is used. Another thing you mentioned was history, which the COOP spec change does not touch. I don't think I understand that part of the spec correctly: it seems like the current specs assumes the top-level browsing context to never change (because the joint session history only mentions one top-level browsing context?), is that true? If not, how do we get the full history for a tab that might have multiple top-level browsing context across its lifetime?

On top of that, I'm not sure how detailed we should be on saying which navigations result in a browsing context group change and which ones are not. Chrome looks at things like whether we have a window.open relationship, but also has a dynamic isolation system that has a list of sites to isolate, and depending on flags etc renderer-initiated navigations might or might not swap browsing context groups. How can we express these things in spec?

Related to this topic also, I wonder if frequent browsing context swaps on same-site navigations might introduce some problems. creis@ mentioned that while breaking scripting relationship on cross-site navigations is expected, breaking it on same-site navigations might have a higher chance of breaking sites, because they may have some expectation of control over their own pages' behavior. A good example is the case at crbug.com/1043162 but with all the sites being same-site. Do you have an opinion on how bad this might be?

Thank you in advance!

[Domenic Denicola]

I haven't spent time looking into this issue yet, but it seems very related to the issue Camille just opened on HTML.

(For Googlers there's also a new thread on the chrome-origin-isolators group, but it suggests engaging in public, and I agree.)

[Rakina Zata Amni]

Oh, thanks Domenic! Adding clamy@ to cc.

Camille opened the Github issue on the session history problem at https://github.com/whatwg/html/issues/5350, which mentions a "browsing session" concept. I think that makes sense and will help in the case of proactive browsing context group swap too.

[Camille Lamy]

+pmeu...@chromium.org +ahe...@chromium.org who have been looking at the issues surrounding browser context group swap for COOP.

[Charlie Reis]

Thanks for bringing this up, Rakina-- you're brought up a lot of the questions that I'm wondering about.

Regarding flexibility about when to change groups, I think that's useful.  I'll note that Chrome uses new browsing context groups when you navigate to privileged pages (e.g., chrome://settings, or extension pages), to prevent web pages from trying to postMessage them, etc.

Regarding session history and https://github.com/whatwg/html/issues/5350, it's worth noting that Chrome does track the browsing context group for each joint session history item (since each FrameNavigationEntry has a SiteInstance with an associated BrowsingInstance).  There's some debate about whether existing window references should work again if you go back, and we lose those relationships if you restore a previous session, but it's useful for keeping things grouped in the same processes they were in before (and sometimes restoring the ability to script across windows).

Charlie

--
You received this message because you are subscribed to the Google Groups "navigation-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to navigation-de...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/navigation-dev/CAMKsNvoUzUBT0FiUD3AZY970%2Bny0OuGzQV%2BbKwp4f7dLYngWWA%40mail.gmail.com.

[Rakina Zata Amni]

Right, as Charlie mentioned, there's also the problem that pmeuleman@ and other COOP people brought up: window.opener etc gets cleared up on browsing context group change - should those be restored on back navigations (the behavior in Chrome is a bit inconsistent I think - sometimes it gets restored and sometimes it does not, but COOP wants to not restore the relationship). I wonder if there's any spec/ongoing discussions on Github etc around this?

Anne (and maybe Domenic/others), do you have any comments on how we should update the specs, and potential problems especially on the same-site browsing context group change case? Happy to do a video call as well if that's easier.

[Domenic Denicola]

I haven't been able to try to load this space into my head to be able to help more concretely, but here are some ideas of what might help:

1. Write up the cases (e.g. with code examples) under consideration. For each, explain things like:

• What the spec model says (e.g. what BCGs get created/reused, ...).
  
• What the observable consequences of the spec's model are.
  
• What Chromium's implementation does, in terms analogous to the spec model.
• What the observable divergences from the spec are, if any.
• For any such divergences, whether we think the spec should be updated, or our implementation.
• How other browsers behave in these scenarios.

The goal here is to get a sense of (a) how far off the spec model and implementation model are; (b) how bad that mismatch is in terms of observable consequences.

2. Clarify how much this is related to session history, or orthogonal to it. I'm worried that our long-standing issues with the session history spec might get in the way of this work. If someone could look into the connection in more detail, and get a clear answer as to how much the potential spec changes from (1) will touch on session history or be separate from it, that would put my mind at ease. (If they are entangled, then probably (1) should also include session history analyses.)

[Arthur Hemery]

pmeuleman@ and I started a doc a while back exactly because we wanted to discuss these issues: https://docs.google.com/document/d/1QmElDQ1ih0RgrVpxKPqTSlL1hSliJb7GX2SVgcdl73M/edit#heading=h.27z5ysjg3r0b (very rough draw).

The main spec issue is that a BrowsingContext technically holds a bunch of state that is never expected to be deleted while the frame is alive. Best example is the session history, meaning changing BrowsingContext should clear session history for the frame. This behavior is clearly wrong and undesired but it might not be as clear for all the state that BrowsingContext holds.

Regarding the dependency on history spec rework, I thought the issue was worse initially because I had no idea joint session history was even a thing. To make history work at a spec level however, and since it is already broken, I think it would be cleaner to work this out first. That sounds like very hard work though!

Because we are pushing with a couple of projects on more browsing context swaps, we probably want to clarify the expected behavior regarding all the things that are stored in the BrowsingContext, and if they should be restored or not on history navigation, even if we can't spec it yet.

Cheers,
Arthur

[Rakina Zata Amni]

Thanks Arthur and Domenic!

Following Domenic's suggestion, I made a doc on chrome vs current spec, and what observable behavior changes might happen (to everyone, feel free to comment/add/etc)

This doesn't really cover the states like name, etc that you talk about in your doc - I agree that those should be made clear too.

Regarding https://github.com/whatwg/html/issues/1454 (history issue that domenic mentioned), I wonder if it's actually blocking? I haven't looked very deeply into it, but it looks like it's talking about having a list-of-tree session history concept + nested browsing context lifetime, while we’re tackling things on the top-level browsing context + browsing context groups side (and the contents of the session history entries?). I might be wrong.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/navigation-dev/CAF07A2WMDrWBe_1kwFG0ox%2BLU6ovt%2BW8L1mqZ4YREOnwoXc0uw%40mail.gmail.com.

[Domenic Denicola]

Wow, great doc Rakina! I left a couple comments, but that is definitely helpful, and makes the problem a lot more concrete to me.

I tentatively agree that #1454 probably won't block this, based on your "None probably?" regarding observable effects on history. If there were some impact on history.length, history.state, or history.scrollRestoration, then we might get in trouble, because #1454 seems to basically be saying that the glue between session history entries and BCs/BCGs is broken. But if there's no impact, then we don't need to specify any changes to history, so it can stay broken... I'm not sure though, history still confuses me.

[Rakina Zata Amni]

Thanks Domenic and others for commenting!

I think the discussions in the doc have more or less converged to some changes needed on the spec. Let me try to summarize what we want to do on a high level:

• Add the possibility of a BCG swap on navigation, which will result in new BCG & BCs with no shared state, severing scripting relationships.
• Make sure the joint history session and history navigation accommodates multiple BCGs/top-level browsing contexts.
• Add support for restoring BCG and its state on history navigations.
• We should reuse the original BCG that we previously used for the page before, if we still have it (including when using COOP - which is different than it) 
• We should restore the state of the BCs (names, scripting relationships, whether it's an auxiliary browsing context/not).
• Since scripting relationships are tied to browsing contexts (see WindowProxy, opener browsing context), we need to specify a way to update the references in other pages' BCs that pointed to the old destroyed BCs to refer to the recreated browsing contexts, maybe by storing more states in the history entries? This part is still unclear.

I think we might want to discuss the details for the changes in a more public forum like Github, in case other parties have opinions on this? (Probably just continue on Camille's issue mostly)

There is also still the concern of the potential of breaking the web (more for proactive BCG swap/ProactivelySwapBrowsingInstance, because site isolation was already here for a while and COOP is opt-in) because scripting relationships will be severed on navigation more often now (even on same-site navigations!). I wonder how we usually handle these kind of changes?

[Kentaro Hara]

-all

Hi Domenic!

Thank you very much for taking care of this discussion :)

Tokyo is not an expert of the navigation standard and is now overloaded with implementing BFcache, so I'm not sure how much we can contribute to making the spec changes. Would it be possible to get some help from you or some spec experts?

[Domenic Denicola]

I don't know of anyone with spare time to work on BFcache-related spec changes; certainly not myself. For what it's worth, I have a lot of confidence in Rakina's abilities here, given her previous work in the standards space and her investigation documents demonstrating good insight into the problem and solution space.

[Rakina Zata Amni]

Thanks Domenic for the help in the doc! As I'm still working on some implementation work, I think I can't update the spec anytime soon, but I think we're OK with updating the specs later (we've already identified most of what needs to change, and nothing seems to be very concerning?). I've also posted the summary above to Camille's Github issue in case it might be of interest to a broader audience.

On the "breaking the web" concern that I mentioned earlier in the thread (some cases where we might lose scripting relationship on same-site history navigation), I think it might not be a big problem (it's a pretty convoluted case, and we're only swapping BCGs on sites with no opener relationships anyways). We might add some metrics on how often this is actually happening, and rethink our position if the data shows otherwise.