Which URIs load where

Based initially on the page's URI scheme, the browser can decide whether to load a page in the chrome process or a content process. For some schemes, you can change the default behavior.

Scheme	Behavior
`about:`	By default, `about:` pages are always loaded in the chrome process. However, when you register a new `about:` page, you can change this default. Two new flags are defined in `nsIAboutModule`: `URI_CAN_LOAD_IN_CHILD`: the page will be loaded in the same process as the `browser` that has loaded it. `URI_MUST_LOAD_IN_CHILD`: the page will always be loaded in a child process. To use one of these flags, return it from your implementation of `getURIFlags` in the code that registers the `about:` URI. If you use these flags, you must register the about page in the framescript for each tab. If you do not set multiprocessCompatible to true in your install.rdf then shims will be used. But the e10s shims will be deprecated soon. Read more here - Bug 1257201.
`chrome:`	By default, `chrome:` pages are always loaded in the chrome process. However, when you register a new `chrome:` page, you can change this default. Two new flags are defined in the chrome.manifest file: remoteenabled: the page will be loaded in the same process as the `browser` that has loaded it. remoterequired: the page will always be loaded in a child process.
`file:`	Always loaded in a content process. Note: This does not mean `file:` URIs can be used freely by code in content processes. Sandboxing may blacklist particular directories and future changes may restrict `file:` URIs to a separate content process, isolated from regular web content. See bug 1187099 how this can affect addons attempting to load files from the profile directory.
`resource:`	Always loaded in a content process.

Document Tags and Contributors