框架脚本的限制

框架脚本使用系统特权运行，并且能够访问 Components 对象，使它们能够使用 XPCOM 对象和 JSM。许多特权的 API 在内容进程中仍然工作。数据结构的处理仍将工作。XHR 和 Workers 仍将工作。但是，某些 API 在 chrome 进程中工作，但在框架脚本中将不工作。本文列出最重要的那些 API。

这是一对文章之一，另一篇是：chrome 脚本的限制。

文件 I/O

你不应该从内容脚本写入或者读取磁盘，特别是配置文件目录。即使这是可能的，你也不应该这样做，应该预期它可能在任何时间停止工作。文件 I/O 应该全部放在 chrome 进程完成。例如：

• nsIFileInputStream
• nsIFileOutputStream
• Constructing a File from a string or nsIFile (但 File 对象可以通过消息管理器发送)
• HTMLInputElement.mozSetFileNameArray (替代: mozSetFileArray)

XUL 和浏览器界面

任何试图接触界面或者与 XUL 相关的东西都很可能在内容进程中不工作。例如：

• nsIPromptService
• nsIFilePicker
• nsIXUL*
• <更多例子待补充>

Services

某些服务不能在框架脚本中工作。

• Services.search
• Services.downloads

Chrome 窗口

任何需要使用 chrome 窗口的东西都不能在内容进程中工作。例如：

• nsISessionStore
• nsIWindowMediator
• <更多例子待补充>

Places API

Places API 不能在框架脚本中使用。例如：

• nsINavHistoryService
• nsINavBookmarksService

内容进程中的 Observers

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

这些必须在内容进程中注册。

内容窗口到 chrome 窗口的 QI

window.QueryInterface(Ci.nsIInterfaceRequestor)
                         .getInterface(Ci.nsIWebNavigation)
                         .QueryInterface(Ci.nsIDocShellTreeItem)
                         .rootTreeItem
                         .QueryInterface(Ci.nsIInterfaceRequestor)
                         .getInterface(Ci.nsIDOMWindow);

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

默认情况下，使用 nsIAboutModule  注册的自定义的 about: 页面在 chrome 进程中加载。这意味着你不能从内容进程访问它们的内容（比如通过 XHR）。

你可以在注册 about: URI 的代码中更改这个默认值。见 about: 和 chrome: URI。

JavaScript 代码模块 (JSM)