The last remaining patch to get Firefox to open and stand up with electrolysis enabled was landed late last week, and, after a few days baking, it has stuck! This means that anyone with a mozilla-central tree can now compile and test Firefox with the content running in a separated process, and start trying your own features and see how well they work or not (or if you can even get to them in the first place). To do this you just need to add one extra configure flag to your mozconfig:
You’re now wondering why this is a compile-time flag and not a simple pref. This flag doesn’t do a whole lot, it mainly switches the main pref browser.tabs.remote to true, but it also switches off hardware acceleration and disables some code that partially break the UI with the pref on. The goal is to get rid of the flag relatively soon (and only use the pref), but for now it’s the easiest way to make sure everyone can focus on the important bits rather than having broken pieces getting in the way.
Things to know after you get the build
The first tab of each window is not remote. All the other tabs that you open are. Progress indicators, favicons, session history and titles don’t work yet (session history and titles are coming soon). Most input like mouse, mouse scroll, keyboard and focus works (although there are corner cases not covered yet). Ah, do not use it with your main profile! Results are unknown.
The content is hosted by the plugin-container process. You should be able to kill it and the content from the remote tabs will disappear (when Firefox is re-rendered, usually when you re-focus the window). You can then open new tabs and the process is recreated just fine.
With these patches in mozilla-central the goal is to make sure everyone can see the progress and test their new features with electrolysis on, and as importantly, do not break what currently already works.
The front-end tasks are being tracked by bug 653064, and platform bugs marked with [e10s] in the whiteboard. Those lists are in no way comprehensive, so do file bugs or ask around with important things that you notice are not tracked yet.
If you want to know more about the patches
On the platform side, the patches that landed added support to input events and were done in bug 583976. nsEventStateManager and nsFocusManager were made aware of the content separation, and when input/focus events are targeted at the content area (i.e. the <browser> element), they’re automatically forwarded (asynchronously) to the content process. On the front-end side, some code was changed to not assume that the content docShell exists, and messages are passed through the message manager when appropriate (e.g. loadURI). I’ll talk more about these details in other posts.
Now that these base patches are in the tree, on the front-end side we’re working on making sure more operations work with electrolysis. Drew has got a neat logging for forbidden chrome->content operations in bug 666713, and the goal is to reduce as much as possible these warning for basic navigation tasks in Firefox, so that the noise can be reduced and we can tackle more features more efficiently. I’ve got more code ready (and some already reviewed) but which I can’t land right now because they’re triggering other [un-]related bugs. I’m already filing these bugs and asking around about them but expect me to start pinging more frequently to ask for help in figuring out and fixing bugs on broader areas of the code.