![\"content_shell](\"https:\/\/blogs.igalia.com\/jaragunde\/files\/2019\/03\/app_shell-sequence.png\")
<\/a><\/p>\nIt creates two objects, ShellMainDelegate and ContentMainParams, then hands control to ContentMain() as implemented in the content module.<\/p>\n
Chrome\u2019s main is very similar, it also spawns a couple objects and then hands control to ContentMain(), following exactly the same code path from that point onward:<\/p>\n
If we took a look to the app_shell, it would be very similar, and it\u2019s probably the same for other shells, so where\u2019s the magic? What\u2019s the difference between the many shells in Chromium? The key is the implementation of that first object created in the main() function:<\/p>\n Those *MainDelegate objects created in main() are implementations of ContentMainDelegate. This delegate will get the control in key moments of the initialization process, so the shells can customize what happens. Two important events are the calls to CreateContentBrowserClient and CreateContentRendererClient, which will enable the shells to customize the behavior of the Browser and Render processes.<\/p>\n The diagram above shows how the ContentMainDelegate implementations provided by the different shells intantiate each their own implementation of ContentBrowserClient. This class runs in the UI thread and is able to customize the browser logic, its API is able to enable or disable certain parameters (e.g. AllowGpuLaunchRetryOnIOThread), provide delegates on certain objects (e.g. GetWebContentsViewDelegate), etc. A remarkable responsibility of ContentBrowserClient is providing an implementation of BrowserMainParts, which runs code in certain stages of the initialization.<\/p>\n There is a parallel hierarchy of ContentRendererClient classes, which works analogously to what we\u2019ve just seen for ContentBrowserClient:<\/p>\n The specific case of extensions::ShellContentRendererClient is interesting because it contains the details to setup the extension API:<\/p>\n The purpose of both ExtensionsClient and ExtensionsRendererClient is to set up the extensions system. The difference lies in the knowledge of the renderer process and its concepts by ExtensionsRendererClient, only methods that make use of this knowledge should be there, otherwise they should be part of ExtensionsClient, which has a much bigger API already. The investigation may continue in different directions, and I’ll try to share more report like this one. Finally, these are the source files for the diagrams and a shared document containing the same information in this report, where any comments, corrections and updates are welcome!<\/p>\n I’ve been investigating the process of Chromium startup, the classes involved and the calls exchanged between them. This is a summary of my findings! There are several implementations of a browser living inside Chromium source code, known as \u201cshells\u201d. Chrome … Continue reading <\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n
\nThe specific implementation of ShellExtensionsRendererClient is very simple but it owns an instance of extensions::Dispatcher; this is an important class that sets up extension features on demand whenever necessary.<\/p>\n\n