Back-forward cache: browsing context change & "fully active" concept

[rakina]

Currently, it seems like documents that are kept alive in the back-forward cache after we navigated away from it are treated as not fully active, and thus the document will be ignored in things that might update its contents/send messages to it, etc.

However, the fully active concept seems to depend on the fact that browsing context (and browsing context group) will never change across navigations. This is not true (at least in Chrome), where we will change browsing contexts (see: #5350).

This will also affect:

• WindowProxy, which will not change the Window object, since the browsing context is not navigated.
• When a method set by setTimeout, setInterval, etc. will be fired, since we're tracking the amount of time a document is fully active.

I wonder if it is enough to fix this by having a "fully active" concept on browsing contexts as well. So a fully active Document is only active if the browsing context it is in is fully active as well + the existing checks. Of course, this is blocked until after we actually update the spec to allow browsing context & browsing context group changes (which is tracked in #5350 I guess?).

[annevk]

Making it depend on browsing session seems reasonable. An alternative might be session history, depending on how that is reworked in #5767. (I expect these two concepts to be intertwined to some extent.)

[domenic]

I wonder if it is enough to fix this by having a "fully active" concept on browsing contexts as well. So a fully active Document is only active if the browsing context it is in is fully active as well + the existing checks.

I'm not sure I fully understand this suggestion, or the original issue. In particular, if a document changes its browsing context/BCG, the current definition of "fully active" seems to work fine.

Perhaps you could spell out the scenario where it falls down, and walk me through what the current definition says, versus what your revised definition would say?

[annevk]

The document does not change its browsing context. The browsing context changes. So where the current definition assumes there is a single top-level browsing context, there are now two. And only one can be considered fully active.

[domenic]

I guess that's the part that's not clear to me, and perhaps is just not yet well-defined. I.e. what will https://html.spec.whatwg.org/#concept-document-bc say in a world where BC/BCG switches happen.

[rakina]

Browsing context change should already be possible with COOP right? However it looks like we're immediately discarding the previous BC when that happens. Not sure on the reason behind that, but I suspect we can remove the "discard" part to allow the previous document be preserved in bfcache. I think we can modify the "fully active" bit of the old browsing context there too.

Making it depend on browsing session seems reasonable.

Do you mean browsing session, or browsing context? Maybe we can have a "fully active" document to depend on whether the "current history step" (proposed in #5767) matches, hmm... (sounds more complex than just having the bit on the browser context too though)

[annevk]

Yeah, COOP currently ignores/breaks bfcache and also doesn't deal well with history, which is broken in its own way.

I would expect the browsing session to identify the current/active top-level browsing context/document for that browsing session.