As Firefox increasingly switches to support running in multiple processes we’ve been finding common problems. Where we can we are designing nice APIs to make solving them easy. One problem is that we often want to run in-content pages like about:newtab and about:home in the child process without privileges making it safer and less likely to bring down Firefox in the event of a crash. These pages still need to get information from and pass information to the main process though, so we have had to come up with ways to handle that. Often we use custom code in a frame script acting as a middle-man, using things like DOM events to listen for requests from the in-content page and then messaging to the main process.
We recently added a new API to make this problem easier to solve. Instead of needing code in a frame script the RemotePageManager module allows special pages direct access to a message manager to communicate with the main process. This can be useful for any page running in the content area, regardless of whether it needs to be run at low privileges or in the content process since it takes care of listening for documents and hooking up the message listeners for you.
There is a low-level API available but the higher-level API is probably more useful in most cases. If your code wants to interact with a page like
about:myaddon just do this from the main process:
Components.utils.import("resource://gre/modules/RemotePageManager.jsm"); let manager = new RemotePages("about:myaddon");
The manager object is now something resembling a regular process message manager. It has
addMessageListener methods but unlike the regular e10s message managers it only communicates with
about:myaddon pages. Unlike the regular message managers there is no option to send synchronous messages or pass cross-process wrapped objects.
about:myaddon is loaded it has
The module documentation has more in-depth examples showing message passing between the page and the main process.
The RemotePageManager module is available in nightlies now and you can see it in action with the simple change I landed to switch
about:plugins to run in the content process. For the moment the APIs only support exact URL matching but it would be possible to add support for regular expressions in the future if that turns out to be useful.