Included is developer documentation for Google Chrome along with other information to help create Themes, Addons, Plugins and various tools for Chrome.

Chromium is separated into three main parts (excluding other libraries): the browser, the renderer, and Webkit. The browser is the main process and represents all the UI and I/O. The renderer is the (often) per-tab sub-process that is driven by the browser. It embeds Webkit to do layout and rendering.

Introduction to the solution file

We have two solution files, chrome.sln which is the normal version that uses V8 as the Javascript engine, and chrome_kjs.sln which uses Webkit's JavaScriptCore (JSC) engine. You will normally want to use the V8 version; we keep the JSC version around to see whether a bug is V8-related.

• The startup code is in the App/chrome_dll and App/chrome_exe projects.
• Common shared library code is in the Libraries/base project. This code is shared between all projects, and we try to keep it as small as necessary.
• Common browser-specific code is in the Browser/common project, this is shared between the browser and the renderer.
• Webkit code is in the projects in Webkit(readonly). On top of this is Google's WebKit(ours)/port which interfaces with Windows, and then WebKit(ours)/glue which is our embedding layer.
• The glue talks to the Browser/renderer project, which represents the subprocess where we run each tab.
• The Browser/browser project provides the user interface, storage, network requests, etc.

Top-level projects

When you check out Chromium, you will notice a number of top-level directories. These directories all live in separate Subversion repositories and are versioned separately (see the Chromium modularization document for details on working with these). These projects are as follows:

• base: Common code shared between all sub-projects. This contains things like string manipulation, generic utilities, etc. Add things here only if it must be shared between more than one other top-level project.
• gfx: Shared graphics classes. These form the base of Chromium's UI graphics, as well as our WebKit port. There are additional graphics classes in chrome/common/gfx which are specific to the Chromium application, and in webkit/port/platform/graphics which are specific to our WebKit port.
• breakpad: Google's open source crash reporting project. This is pulled directly from Google Code's Subversion repository.
• build: Build-related configuration shared by all projects.
• chrome: The Chromium browser (see below).
• data: Data files for running certain tests.
• gears: Gears.
• googleurl: Google's open source URL parsing and canonicalization library. This is pulled directly from Google Code's Subversion repository.
• net: The networking library developed for Chromium. This can be used separately from Chromium when running our simple test_shell in the webkit repository. See also chrome/common/net.
• sandbox: The sandbox project which tries to prevent a hacked renderer from modifying the system.
• skia: Google's Skia graphics library developed for Android. This is a copy from Android's tree. Our additional classes in base/gfx wrap Skia.
• testing: Contains Google's open-sourced GTest code which we use for unit testing.
• third_party: A bunch of external libraries such as image decoders and compression libraries. There are also some Chrome-specific third-party libraries in chrome/third_party.
• tools
• v8: The V8 Javascript library. This is pulled directly from Google Code's Subversion repository.
• webkit: All of Chromium's Webkit-related stuff:
• activex_shim: A shim for running some Active-X controls in Chromium.
• build: Project files and configurations for the rest of the projects.
• data: Most of the directories contain data used by unit tests of our porting layer. the layout_tests directory is WebKit's layout test suite that we pull directly from Apple.
• glue: The glue layer is the embedding layer. It converts between Webcore types and our application's types (mostly STL), and provides more convenient methods that mirror a lot of Webcore's objects we need access to.
• pending: Files we have forked from WebKit. We don't modify them directly, since third_party is supposed to be unmodified. Instead, we copy them here, modify them, and fix the solution file to point to the new versions. Deprecated and soon to go away. All WebKit changes should be submitted to Apple.
• port: A platform-specific implementation for OS-specific things like graphics, text measurement, and networking.
• third_party: Contains a copy of Webcore and JavaScriptCore from Apple.
• tools
• layout_tests: Scripts for running WebCore's layout tests.
• merge: Scripts for helping merge to WebKit's tree.
• npapi_layout_test_plugin: A special plug-in used by some of our tests to exercise the plugin layer.
• test_shell: A very simple standalone browser. This allows testing of our glue and port code without having to compile and run the very large Chromium application.

Quick reference for the directory tree under "chrome/"

* app: The "app" is the most basic level of the program. It is run on startup, and dispatches to either the browser or renderer code depending on which capabilities the current process is in. It contains the projects for chrome.exe and chrome.dll. You won't generally need to change this stuff except for resources like images and strings.

o locales: Projects for building localized DLLs.

o resources: Icons and cursors.

o theme: Images for the theme of the window.

* browser: The frontend including the main window, UI, and the backend for the application which handles all I/O and storage. This talks to the renderer to manage web pages.

o autocomplete: Code for the combined address and search bar ("omnibox") - the UI and the code that organizes data to show in it.

o automation: Automation is the system for communicating with the test program that drives the UI tests. This component receives and executes commands from the test program, and forwards results. It communicates with the code in test/automation.

o dom_ui: Allows UI to be shown in a tab using WebKit, e.g. the New Tab page, or HTML-based Gears dialogs.

o hang_monitor: Code for detecting hung windowed plugins and showing a UI.

o history: History includes storage of web page URLs, times, etc., as well as favicons, thumbnails, and the full text index of all visited pages.

o net: Some Chromium-specific network code (non-Chromium-specific code is in the top-level net directory). This currently contains code for DNS prefetching. It should probably be merged with common/net. See also renderer/net.

o printing: Code for printing web pages.

o resources: HTML pages and other resources used by the browser, for example the New Tab page, the about: pages, etc.

o safe_browsing: The safe browsing client.

o security/resources: The SSL error roadblock pages.

o shell: The JavaScript debugger shell.

o tabs: The browser window tab strip.

o views: Most user interface components of the browser live here, including dialog boxes and other components like the Bookmarks bar. These are browser-specific additions to the more generic objects in chrome/views.

o webdata: Database for holding web page/site specific capabilities such as passwords.

* common: Files shared between the browser and the renderer, as well as other random projects. This is the code specific to Chromium (and not applicable to being in base) but that is shared between the chrome/browser and the chrome/renderer directories..

o gfx: Graphics and rendering related helper code specific to Chromium. Some graphics stuff that mush be shared with outer toplevel modules is in base/gfx.

o net: Some Chromium-specific stuff on top of the net top-level module. This should be merged with browser/net.

* installer: Source files and projects for making the installer (MSI package).

* plugin: Code for running browser plugins in other processes.

* renderer: Code for the subprocess in each tab. This embeds WebKit and talks to browser for I/O.

o automation: Allows the browser to communicate with the DOM of a web page. This is used for tests to get web page content from the renderer up to the browser.

* test:

o automation: Used by tests to drive the browser UI, for example, in test/ui, test/startup, etc. This communicates with browser/automation in the browser.

o page_cycler: Code for running page cycler tests (for performance measurement). See tools/perf/dashboard.

o reliability: Reliability tests for distributed testing of page loads for reliability metrics and crash finding.

o selenium: Code for running the selenium tests, which is a third-party test suite for Ajaxy and JavaScript stuff. See test/third_party/selenium_core.

o startup: Tests for measuring startup performance. See tools/perf/dashboard and tools/test/reference_build.

o ui: UI tests for poking at the browser UI, opening tabs, etc. It uses test/automation for doing most operations.

o unit: The base code for the unit tests. The test code for individual tests is generally alongside the code it is testing in a *_unittest.cc file.

* third_party: Third party libraries that are specific to Chromium. Some other third party libraries are in the top-level third_party library.
* tools

o build: Tools and random stuff related to building.

+ buildbot: Buildbot configuration. Buildbot manages our automated build system. See third_pary/buildbot.

+ win: Windows build stuff, including some .vsprops files used for project properties and scripts.

o memory: Tools for memory stuff. Currently includes gflags for setting page heap options.

o perf/dashboard: Code for converting performance logs (for example test/startup_test) into data and graphs.

o profiles: Generator for random history data. Used to make test profiles.

o test

+ image_diff: Tool for comparing images. Written for Webkit pixel tests, but is not currently run.

+ reference_build: Checked in copy of an old version of Chromium. Used by the startup and page cycler tests to compare against the performance of the current build to identify variations due to the execution environment.

+ testserver: A simple HTTP web server. Used to provide data for unit tests that must be retrieved over HTTP.

* views: A simple framework for doing UI development, providing rendering, layout and event handling. Most of the browser UI is implemented in this system. This directory contains the base objects. Some more browser-specific objects are in browser/views.

Code paths for common operations

Application startup

• 1. Our WinMain function is in chrome/app/main.cc, and is linked in the chrome_exe project.
• 2. WinMain launches the Google Update Client, which is the installer/autoupdater. It will find the subdirectory for the current version, and load chrome.dll from there.
• 3. It calls ChromeMain in the newly loaded library, which is in chrome_main.cc in the chrome_dll project.
• 4. ChromeMain does initialization for common components, and then forwards to either RendererMain in chrome/renderer/renderer_main.cc if the command line flag indicates that this should be a subprocess, or BrowserMain in chrome/browser/browser_main.cc if not to load a new copy of the application. Since this is startup, we're launching the browser.
• 5. BrowserMain does common browser initialization. It has different modes for running installed webapps, connecting to the automation system if the browser is being tested, etc.
• 6. It calls LaunchWithProfile in browser_init.cc which creates a new Browser object in chrome/browser/browser.cc. This object encapsulates one toplevel window in the application. The first tab is appended at this time.

Tab startup & initial navigation

• 1. Browser::AppendTab in chrome/browser/browser.cc is called to append a new tab.
• 2. It will create a new TabContents object from browser/tab_contents.cc. There are different specializations of the TabContents objects for different URL types. For web content, this specialization is WebContents in chrome/browser/web_contents.cc. There are also a few other types for more specialized tabs. We will assume we are creating a web page.
• 3. WebContents creates a RenderViewHost in the static RenderProcessHost::CreateRenderViewHost in chrome/browser/render_process_host.cc. This function either spawns a new renderer process, or re-uses an existing RenderProcess. RenderProcess is the object in the browser that represents a single renderer subprocess.
• 4. The TabContents sets up a NavigationController in chrome/browser/navigation_controller.cc. The navigation controller represents the back-forward history for that tab. This object may be re-used between different TabContents types (for example, between a history search tab and web content).
• 5. The navigation controller is instructed to navigate to the URL for the new tab in NavigationController::LoadURL. "Navigating from the URL bar" from step 3 onward describes what happens from this point.

Navigating from the URL bar

• 1. When the user types into or accepts an entry in the URL bar, the autocomplete edit box determines the final target URL and passes that to AutocompleteEdit::OpenURL. (This may not be exactly what the user typed - for example, an URL is generated in the case of a search query.)
• 2. The navigation controller is instructed to navigate to the URL in NavigationController::LoadURL.
• 3. At each transition, the navigation controller checks to see if the current TabContents type is appropriate, and replaces it if necessary. For the first navigation, this is not necessary since the appropriate type was created initially.
• 4. The NavigationController calls TabContents::Navigate with the NavigationEntry it created to represent this particular page transition. It will create a new RenderViewHost if necessary, which will cause creation of a RenderViewHost in the renderer process. A RenderView won't exist if this is the first navigation, or if the renderer has crashed, so this will also recover from crashes.
• 5. Navigate forwards to RenderViewHost::NavigateToEntry. The NavigationController stores this navigation entry, but it is marked as "pending" because it doesn't know for sure if the transition will take place (maybe the host can not be resolved).
• 6. RenderViewHost::NavigateToEntry sends a ViewMsg_Navigate to the new RenderView in the renderer process.
• 7. When told to navigate, RenderView may navigate, it my fail, or it may navigate somewhere else instead (for example, if the user clicks a link). RenderViewHost waits for a ViewHostMsg_FrameNavigate from the RenderView.
• 8. When the load is "committed" by WebKit (the server responded and is sending us data), the RenderView sends this message, which is handled in RenderViewHost::OnMsgNavigate.
• 9. The NavigationEntry is updated with the information on the load. In the case of a link click, the browser has never seen this URL before. If the navigation was browser-initiated, as in the startup case, there may have been redirects that have changed the URL.
• 10. The NavigationController updates its list of navigations to account for this new information.

Navigations and session history

Each NavigationEntry stores a page ID and a block of history state data. The page ID is used to uniquely identify a page load, so we know which NavigationEntry it corresponds to. It is assigned when the page is committed commit, so a pending NavigationEntry will have a page ID of -1. The history state data is simply a WebCore::HistoryItem serialized to a string. Included on this item are things like the page URL, subframe URLs, and form data.

• 1. When the browser initiates the request (typing in the URL bar, or clicking back/forward/reload)
• 1. A WebRequest is made representing the navigation, along with extra information like a page ID for bookkeeping. New navigations have an ID of -1. Navigations to old entries have the ID assigned to the NavigationEntry when the page was first visited. This extra information will be queried later when the load commits.
• 2. The main WebFrame is told to load the new request.
• 2. When the renderer initiates the request (user clicks a link, javascript changes the location, etc):
• 1. WebCore::FrameLoader is told to load the request via one of its bajillion varied load methods.
• 3. In either case, when the first packet from the server is received, the load is committed (no longer "pending" or "provisional").
• 4. If this was a new navigation, WebCore will create a new HistoryItem and add it to the BackForwardList, a WebCore class that we have forked. In this way, we can differentiate which navigations are new, and which are session history navigations.
• 5. RenderViewDidCommitLoadForFrame handles the commit for the load. Here, the previous page's state is stored in session history, via the ViewHostMsg_UpdateState message. This will tell the browser to update the corresponding NavigationEntry (identified by RenderView's current page ID) with the new history state.
• 6. RenderView's current page ID is updated to reflect the committed page. For a new navigation, a new unique page ID is generated. For a session history navigation, it will be the page ID originally assigned when it was first visited, which we had stored on the WebRequest when initiating the navigation.
• 7. A ViewHostMsg_FrameNavigate message is sent to the browser, updating the corresponding NavigationEntry (identified by RenderView's newly updated page ID) with the new URL and other information.

Dev: Getting around the Chrome Source Code

I was running Chrome fine for many days and all of a sudden on a start up at get a flash on the screen for about 1/10th of a second and it never loads. I uninstalled and reinstalled, but nothing works except that 1/10 second flash. I tried getting a screen print of it and this is all that I got:

http://www.chromeplugins.org/chrome/...h/#comment-221

Any suggestions? I'd surely like to use it again.

Thanks,

Sky~

Have you tried starting Chrome with the --first-run switch?

Originally Posted by Chrome

Have you tried starting Chrome with the --first-run switch?

I am not sure what "first-run switch" is. If you mean, have I tried starting it after a cold boot, yes, I have. It's exactly the same. A 1/10 like flash and that's all there is to it.

Sky~

On your shortcut from Chrome, try right clicking then go to properties and at the end of the location add a space then:

--first-run

Click apply, then double click the shortcut to start Chrome. If it does work and you get Chrome running, go back and remove the first-run command from the file location.

Help! It ran the tail end of the installation, by copying my favorites, etc., from Mozilla and I okay'd everything, but then it disappeared. So I tried starting it and got nothing. Then I removed the --first-run and it went back to its 1/10 second flash again. :/

I even have Chrome as the default browser. :/ Nothing seems to make it work.

Yesterday, it just came on all by itself. Hooooray!

Now if only I could use my mouse pad to scroll up when I use Chrome.

I love Chrome, except for the mouse problem. I have to have my gmail account in FireFox and do a ALT+TAB to toggle back and forth. Too bad it's gotta be in FireFox. :/

I don't know what fixed it.

Sky~

Originally Posted by Skyrider

Yesterday, it just came on all by itself. Hooooray!

Excellent, did your Chrome version update to .30 by any chance?

Now if only I could use my mouse pad to scroll up when I use Chrome.

Ok download this, run it and follow the instructions. It's a patch to fix the Chrome scrolling issue, and from the comments i have seen it has a fairly high success rate.

Let me know if it works.