DEPS for back_forward_cache*

[Fergal Daly]

In https://crrev.com/c/7496119 I suggested that the BackForwardCache should be a WebContentsObserver. This seems like the right way to do it but c/b/renderer_host/DEPS disallows c/b/web_contents . I thought of moving BFCache into web_contents (since the cache is a per-WC thing) but that still leaves lots of DEPS violations.

What's the right way to solve this? Make an exception for back_forward_cache_impl to depend on WC? Put stuff into a back_forward_cache/ directory?

Thanks,

F

[Dave Tapuska]

BackForwardCache is owned by the NavigatorController which is owned by the Navigator which is owned by the FrameTree.

This seems like a far path from WebContents. I don't know if making BFCache a WebContentsObserver is actually best because the BFCache may not be the primary frame tree owned by the WebContentsImpl.

Rakina what did you have in mind?

dave.

--
You received this message because you are subscribed to the Google Groups "content-owners" group.
To unsubscribe from this group and stop receiving emails from it, send an email to content-owner...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/content-owners/CAAozHLkYwmgttZery8votZ2CVjTCv7akTjNKp2Lu1GU5nbq0Jw%40mail.gmail.com.

[Alex Moshchuk]

Note that we also have this guidance in content/browser/renderer_host/README.md:

"Code in this directory can't call up to the WebContents “layer,” except through delegate interfaces (e.g. RenderFrameHostDelegate). This is to separate out code that deals with the renderer process and code that deals with the tab."

Do we really want to consider BFCache as a per-WebContents, per-tab concept? I tend to agree with Dave that it seems more like a per-NavigationController concept, and maybe it could eventually be used in non-primary FrameTree cases even if that's not the case today. In which case, depending on WebContents doesn't seem that desirable.

Alex

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/content-owners/CAHgVhZWBae8aEvjwxEc%2BTwHmWZt%3DUuK4J0MLEFkfFLWrxv6%3DnQ%40mail.gmail.com.

[Fergal Daly]

On Sat, 21 Feb 2026 at 07:46, Alex Moshchuk <ale...@chromium.org> wrote:

Note that we also have this guidance in content/browser/renderer_host/README.md:

"Code in this directory can't call up to the WebContents “layer,” except through delegate interfaces (e.g. RenderFrameHostDelegate). This is to separate out code that deals with the renderer process and code that deals with the tab."

Do we really want to consider BFCache as a per-WebContents, per-tab concept? I tend to agree with Dave that it seems more like a per-NavigationController concept, and maybe it could eventually be used in non-primary FrameTree cases even if that's not the case today. In which case, depending on WebContents doesn't seem that desirable.

I don't have a strong opinion on what it should be but per-WC/tab is how I think of it. It occurred to me that Webium might break this but actually, surface-embed will be a WC so that's not the case.

For fenced frames, they are attached (transitively) to the primary main frame's BFCache, even though their inner frame tree has its own nav controller's BFCache. That BFCache sits unused which seems odd.

Rakina also mentioned some problems that arose because pages in BFCache lack a frame-tree. I'll let her fill in the details.

It's unclear to me when we would want a BFCacheable non-main frame and I also don't think the current CL looks too bad. Certainly not to the extent that I would want to relocate where BFCache sits in the object hierarchy. Then again, the current CL technically should find all of the BFCaches associated with this frame tree even though only one is used, and signal the visibility change to all of them. I think WebContentsImpl::GetOutermostMainFramesForViewChange currently fails to look inside any of these inner BFCaches,

F

[Rakina Zata Amni]

Some of the content owners (me, creis@, alexmos@) discussed this yesterday.

On BFCache being in content/browser/renderer_host instead of its own directory under content/browser/back_forward_cache or something:

• It seems like the rationale behind the DEPS ban for WebContents in content/browser/renderer_host is because the directory is supposed to be about interfacing with the renderer process and it shouldn't be dealing with tab-level things. This seems less relevant for BackForwardCache which doesn't directly interact with the renderer (it does trigger sending IPCs for freezing etc but it's through RFH / RVH and not directly).
• I mentioned preloading (prerender etc) already lives in content/browser/preloading, and it's pretty much doing similar things with BFCache and is similarly heavily involved with the navigation code (which would still live in renderer_host). Looking at this, there's no clear reason why BFCache can't just be in its own directory.

On BFCache being a WebContents level object:

• I explained that the BackForwardCache(Impl) object that is used for any decision right now is only the primary FrameTree's one.
• We do support BFCaching pages that have fenced frame inner FrameTrees in them, but that is also purely controlled by the primary FrameTree's BackForwardCacheImpl object. We start from the primary main frame and traverse down into all RFHs when checking BFCache eligibility, but only save the NotRestoredReasons and all other info for all the frames on the primary FrameTree's BackForwardCacheImpl.
• Related to the point above, I wonder if there are potential bugs right now where e.g. a frame in an inner fenced frame tree triggers an eviction. If it accidentally reached into the inner FrameTree's BackForwardCacheImpl it might not actually trigger eviction correctly.
• We don't support (and have no plans of supporting in the future) BFCaching inner FrameTrees separately (including GuestViews). 

From the points above we agree that moving the and also making BFCache be 1:1 with WebContents seems doable and might be good to prevent potential interactions with unneeded inner FrameTree BackForwardCacheImpl objects. Whether they're worth the effort of doing them is not clear :)