This article needs a technical review. How you can help.
Frame scripts run with system privileges and have access to the Components object, enabling them to use XPCOM objects and JSMs. Many privileged APIs will just work in a content process. Anything that just manipulates data structures will just work. XHR and Workers will work. However, some APIs that work in the chrome process will not work in a frame script. This article lists the most important of these APIs.
This is one of a pair of articles: the other one lists limitations of chrome scripts.
File I/O
You should not write to or read from the disk from a frame script, in particular the profile directory. Even if this is possible, you should not do it and may expect that it could stop working at any time. File I/O should all be done in the chrome process. For example:
nsIFileInputStream
nsIFileOutputStream
- Constructing a
File
from a string ornsIFile
(butFile
objects can be sent via message manager) HTMLInputElement.mozSetFileNameArray
(alternative:mozSetFileArray
)
XUL and browser UI
Anything that tries to touch the browser UI or anything to do with XUL is likely to not work in the content process. For example:
nsIPromptService
nsIFilePicker
nsIXUL*
- <need more examples>
Services
Some services will not work in frame scripts.
- Services.search
- Services.downloads
Chrome windows
Anything that needs to use chrome windows will not work in the content process. For example:
nsISessionStore
nsIWindowMediator
- <need more examples>
Places API
The Places API can't be used inside a frame script. For example:
Observers in the content process
As noted in Observers in the chrome process, most observers should be registered in the chrome process and will not work in the content process. The exceptions are:
content-document-global-created
document-element-inserted
outer-window-destroyed
inner-window-destroyed
dom-window-destroyed
These must be registered in the content process.
QI from content window to chrome window
window.QueryInterface(Ci.nsIInterfaceRequestor) .getInterface(Ci.nsIWebNavigation) .QueryInterface(Ci.nsIDocShellTreeItem) .rootTreeItem .QueryInterface(Ci.nsIInterfaceRequestor) .getInterface(Ci.nsIDOMWindow);
nsITabChild
, that cannot be converted to an nsIDOMWindow
, so the second getInterface
call here will fail.If you want a chrome window: send a message from the content process using the message manager. The target
property of the object passed into the message handler in the chrome process is the XUL <browser>
receiving the message, and you can get the chrome window from that (Note: I'm not really sure how...).
nsIAboutModule
By default, custom about:
pages registered using nsIAboutModule
are loaded in the chrome process. This means that you can't access their content from the content process (via XHR, for example).
You can change this default in the code you use to register the about: URI. See about: and chrome: URIs.