Posted by: felipe | December 16, 2010

First steps into an e10s Firefox

Last month we started working on a project to stand up a Firefox instance running e10s. Now we’ve got some first tryserver builds (links below) in which it’s possible to interact with the webpages, so if you’re interested I’m going to talk about how was the process to get to this point so far, and what are the next steps to do.

First we started by using the test-ipc.xul to check how the platform support for e10s was working. This is a simple XUL window with a <browser remote=”true”> element and some test functions. Upon disabling hardware acceleration and making same-compartment checks non-fatal, the window stood up and displayed the webpage.

After that we went to get the regular Firefox browser window standing up. There were various points during the startup functions (BrowserStartup and delayedStartup) that threw exceptions and thus the functions never completed. Most of the cases are calls trying to access .contentDocument or .docShell properties, which won’t exist for content anymore and will have to be replaced for messages between the processes. After commenting out a few places and making small changes to others, those two functions completed and the UI began to work (for a very broad definition of work, of course).

The next major step was to set up a mechanism to pass events from chrome to content. After talking with smaug, we went for a mechanism tied to the EventStateManager that will automatically forward selected events to content if their target ends up being the <browser> element, and one that is hopefully easy to extend for each new event that we want to add later. This just involves adding them to a whitelist and writing some simple code to {de}serialize them at the IPC level.

With this mechanism in place we already hooked up mouse, mouse scroll and basic keyboard events, plus a kinda-broken focus (and a simple plan to try to hook something to the focus manager)

At this point, we have a Firefox window starting up where you can load up tabs and interact with the pages at a basic level. There’s not progress indicators or tab titles yet, which makes it sometimes hard to tell if things are working or not. Also, focus get lost often, specially if you try to close tabs, which is not working either :).

In any case, a lot of people are curious to test it and to get a feeling of how things are working, so there are try builds available: OS X, Linux, and Windows.
Remember that all of this is only planned for future versions of Firefox. Use the builds with a testing profile and expect things to break!

Update: forgot to mention that you need to type full URLs, including the protocol:// part. Also, if you’re interested, these are the changesets pushed to this build, and I’m keeping the patches (plus some others) in a patch queue.

In the next blog posts I’ll talk more about some of the specific fixes so far, the attempts to run tests on these builds, and some of the approaches that will be needed to adapt the front-end to e10s.



  1. Thanks for making the try builds available, Felipe!

    I tried the build. Yep, almost every functions are not working, and the working ones are broken. 😀 But the whole browser seems to be very fast. The page loading and the UI (for example tab animation) too. Idk this is because of e10s or just the minimized Fx. I hope the first does the majority of it.

    I stay tuned and check back when the next iteration will be available.

    PS: Is my interpretation is good that you separated content and chrome in this build? I thought there will be at least too Fx.exe in task manager, but there is only one. Are you doing the separation with threads in one process?

    • Yes, they’re separated on two different processes. The chrome is hosted by firefox.exe and the content by plugin-container.exe

      • In my opinion there sould be only one process and a good exception handler.
        firefox should host a subprocess for every tab and these tabs should host threads for content like, html and plugins. Every part of it should be well encapsulated meaning if one part fails only the substructure crashed.
        If you want to go further you can even substitute a brocken part of the whole subprocess so it would never show if it crashed unless you look at the logs.

  2. Hi!

    But in the future, there will be 3 processes, for chrome, content, and plugins, won’t be?

  3. Shouldn’t it be possable to multithread just by changeing the compiler?
    That is one of the benefits for using object oriented programing or
    is it not used for foxdev?


%d bloggers like this: