Which URIs load where

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.

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.

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.