Esta traducción está incompleta. Por favor, ayuda a traducir este artículo del inglés.

Los scripts de proceso son nuevos en Firefox 38.

Si esta utilizando el addon sdk, puede utilizar el remote/parent módulo remoteRequire en su lugar.

Cuando necesite ejecutar código en el proceso de contenido para acceder al contenido web, debe utilizar secuencias de frame scripts. Sin embargo, un problema con los scripts es que se pueden cargar varias veces en el proceso de contenido, en varios ámbitos que están aislados unos de otros. Por ejemplo, si llama a la funcion loadFrameScript() del gestor de mensajes de script, entonces el script se cargará por separado en todas las pestañas abiertas. Esto puede causar un problema que las secuencias de scripts de trama están interactuando con un servicio global en el proceso de contenido.

Por ejemplo, en multiprocesos Firefox, si necesita usar nsIContentPolicy to register a content policy, you must do this in the content process. para registrar una política de contenido, debe hacerlo en el proceso de contenido. Pero si lo registra en una secuencia de frame script la secuencia de frame script se carga más de una vez, registrará la política de contenido más de una vez, lo que probablemente no es lo que pretende.

De forma similar, algunas notificaciones de observadores deben registrarse en el frame script, pero si lo hace en una secuencia de frame scrip, se cargara más de una vez, recibirá varias notificaciones, para ese evento.

La solución en estos casos es usar un script de proceso en lugar de un frame script.

You can load a process script by accessing a parent process message manager and calling its loadProcessScript() function. The following code uses the global parent process message manager, which will load the script into the the chrome process and any child processes:

// chrome code
let ppmm = Cc["@mozilla.org/parentprocessmessagemanager;1"]
  .getService(Ci.nsIProcessScriptLoader);
ppmm.loadProcessScript("chrome://whatever/process-script.js", true);
ppmm.addMessageListener("Hello", function(msg) { ... });

The process script's global is a child process message manager, which enables the process script to receive messages from the chrome side, and to send messages to the chrome side:

// process-script.js
if (Services.appinfo.processType == Services.appinfo.PROCESS_TYPE_CONTENT) {
  dump("Welcome to the process script in a content process");
} else {
  dump("Welcome to the process script in the main process");
}

// Message is sent using ContentProcessMessageManager
sendAsyncMessage("Hello");

In this example, the dump() statement will run once in each content process as well as in the main process. This example also figures out whether it is running in the chrome or in a content process by looking at the process type in Services.appinfo.

In just about every respect, using process scripts is like using frame scripts:

  • you can pass the allowDelayedLoad to loadProcessScript(). If you do, you must call removeDelayedProcessScript() when your extension is disabled or removed
  • the message-passing APIs are the same: sendAsyncMessage() is available in both directions, while sendSyncMessage() is available from content to chrome only
  • process scripts are system-privileged, and have access to the Components object. However, process scripts are subject to the same kinds of limitations as frame scripts (for example, no file system access).
  • process scripts stay loaded until their host process is closed.
  • the environment for process scripts is similar to that for frame scripts. However, you don't get access to web content or DOM events from a process script.

Retrieving the content frame message manager for a content window

When an observer notification in a process script contains a content document or window it can be useful to not use talk through the child/parent process message managers but through the window's content frame message manager, e.g. if responses should be processed by a frame script instead of the process script.

This can be achieved by traversing the docshell tree up to the top window and then retrieving its content message manager, as follows:

function contentMMFromContentWindow(window) {
  let tree = window.QueryInterface(Ci.nsIInterfaceRequestor).getInterface(Ci.nsIDocShellTreeItem);
  let top = tree.sameTypeRootTreeItem;
  let iface = QueryInterface(Ci.nsIDocShell).QueryInterface(Ci.nsIInterfaceRequestor);
  return iface.getInterface(Ci.nsIContentFrameMessageManager);
}

This is intended for unprivileged pages running in a content process. Chrome-privileged pages or things running in the parent process may require special treatment.

If the above doesn't work try this:

function contentMMFromContentWindow_Method2(aContentWindow) {
    return aContentWindow.QueryInterface(Ci.nsIInterfaceRequestor)
                         .getInterface(Ci.nsIDocShell)
                         .QueryInterface(Ci.nsIInterfaceRequestor)
                         .getInterface(Ci.nsIContentFrameMessageManager);
}

Etiquetas y colaboradores del documento

Etiquetas: 
 Colaboradores en esta página: abner_partner, dkocho4
 Última actualización por: abner_partner,