5bf8bc23cb
We add an additional counter to the shared memory to track whether all sync calls have made it to the network service. If there are still pending writes to be committed, then Cookies() issues an IPC. Bug: 380864710 Change-Id: Ib1eb97e1475e1efd6977c1cfa07273d5b89d0e8e Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6373304 Reviewed-by: Dave Tapuska <dtapuska@chromium.org> Commit-Queue: Aldo Culquicondor <acondor@chromium.org> Reviewed-by: Kenichi Ishibashi <bashi@chromium.org> Reviewed-by: Oksana Zhuravlova <oksamyt@chromium.org> Cr-Commit-Position: refs/heads/main@{#1435404}
What is content/browser/renderer_host?
This directory contains code that can be loosely categorized as "handling the renderer," covering a wide range of topics (navigation, compositing, input, etc). Many of the classes represent a browser-side version of a renderer concept (e.g., RenderFrameHostImpl is the browser-side equivalent of RenderFrameImpl). Refer to the class-level comments on how each class relates to or interacts with the renderer.
Note that many of the key classes here are defined in content/public and
exposed to //content embedders, with implementations living in
content/browser/renderer_host.
Rough Categories
A non-exhaustive list of rough categories and descriptions for the code within
renderer_host is below. When adding something that falls into the
miscellaneous category, consider if it belongs in a separate directory, either
under content/browser/ or under content/browser/renderer_host.
Browser-side representation of documents and frame-tree-related renderer-side objects
Allows the browser-side code to represent document and frame-tree related concepts, and communicate with the renderer-side.
Some important classes include:
- FrameTree and FrameTreeNode: Represents the frames in the frame tree of a page.
- RenderFrameHost: Roughly represents a document within a frame, although it does not (yet) change for every new document.
- RenderFrameProxyHost: A placeholder for a frame in other SiteInstanceGroups and renderer processes.
- RenderViewHost: Represents a page within a given SiteInstanceGroup.
- RenderWidgetHost: A group of contiguous same-SiteInstanceGroup frames that can paint or handle input events as a single unit.
For diagrams and explanations of how those classes fit with each other, see also this documentation and docs/frame_trees.md.
Connections between browser and renderer/GPU processes, process-related code
Represents child processes (e.g., renderers, GPU, etc) and their connection to the browser process.
An important class in this category is RenderProcessHost, which represents the browser side of the browser <-> renderer communication channel. There will be one RenderProcessHost per renderer process.
Navigation
Navigation handling code, coordinating the browser & renderer from navigation start to finish. Also keeps track of the session history entries created by the committed navigations.
Some important classes include:
- NavigationRequest: Represents a navigation attempt, and tracks information related to it.
- NavigationController: Manages the joint session history for a frame tree.
- NavigationEntry and FrameNavigationEntry: Represents joint session history items (for pages), made up of a tree of session history items (for frames).
See also docs/navigation.md and docs/session_history.md.
Compositing, input, display
Coordinates handling of input, display, and compositing between the browser, renderer, and GPU processes.
Some important classes include:
- RenderWidgetHostView*: The browser owned object that mediates the blink::VisualProperties to be used by an embedded Renderer.
- DelegatedFrameHost: Used by RenderWidgetHostView to control which viz::Surface of an embedded Renderer the GPU process will display EmbeddedFrameSinkImpl: The browser owned object that mediates between an embedded Renderer and the GPU process. Allowing for the creation of Renderer-GPU Mojo connections.
- viz::HostFrameSinkManager: The browser owned object, accessed via GetHostFrameSinkManager, that controls the Browser-GPU Mojo connection. Used to establish future connections for Renderers, as well as to control what viz::Surfaces to display.
Misc features that heavily interact with the renderer
Examples: loading/networking, file/storage, plugins, UI, fonts, media, accessibility.
Layering restriction with WebContents
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. This is enforced by the DEPS.