Firefox

Limitações de frame scripts

Esta tradução está incompleta. Por favor, ajude a traduzir este artigo do Inglês.

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.

Restrições de Segurança no Acesso de Ficheiro

Processes that host remote content are isolated from the local system through a content security sandbox. One of the functions of the sandbox is to restrict access to the local file system by processes that host remote content. Since frame and process scripts often execute in remote content processes these scripts are subject to the same file access rules placed on remote content. Therefore frame scripts should not attempt to access the local file system directly, as these calls will fail.

Examples of APIs Add-on authors should avoid in frame scripts:

XUL e IU de navegador

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:

Serviços

Some services will not work in frame scripts.

  • Services.search
  • Services.downloads

Janelas de Chrome

Anything that needs to use chrome windows will not work in the content process. For example:

Places API

A API de Places não pode ser utilizada dentro de uma frame script. Por exemplo:

Observadores no processo de conteúdo

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:

These must be registered in the content process.

QI from content window to chrome window

There's a particular pattern often used to get from a content window to the associated chrome window. It looks something like this:
 
window.QueryInterface(Ci.nsIInterfaceRequestor)
                         .getInterface(Ci.nsIWebNavigation)
                         .QueryInterface(Ci.nsIDocShellTreeItem)
                         .rootTreeItem
                         .QueryInterface(Ci.nsIInterfaceRequestor)
                         .getInterface(Ci.nsIDOMWindow);
This will no longer work. In the content process the root tree item is an 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.

Módulos de código de JavaScript (JSMs)

In multiprocess Firefox, a JSM loaded into the content process does not share any state with the same JSM loaded into the chrome process. See the entry in the Limitations on chrome scripts page.

Etiquetas do documento e contribuidores

 Contribuidores para esta página: mansil
 Última atualização por: mansil,