
Electrolysis – run web content in a separate process from Firefox - tosh
https://wiki.mozilla.org/Electrolysis
======
whoisthemachine
I use this occasionally, it works okay.

I have to say though, with the introduction of the GGC, and all of the
improvements to the JS runtime recently in Firefox, that it has gotten much
faster.

Electrolysis should bring "smoothness" to the entire UI as one site should not
be able to halt the UI thread for the rest of the browser any more.

------
ck2
I feel like people stealth copy links from my comments sometimes.

Maybe I am just paranoid, lol

Anyway, I'll add this:

[http://arewee10syet.com/](http://arewee10syet.com/)

~~~
tosh
Confirmed: I did find the wiki page through your comment and thought it would
be a great submission.

You are not paranoid if they are really watching you :D

~~~
ck2
Yeah don't feel bad, someone else did it to my Chrome runs Android apps
submission the other day too.

I've got more useless points than I know what to do with so no problem with
others having some.

ps. I think a better title that might not get mod-changed would be _" Mozilla:
Electrolysis"_

~~~
tosh
Title updated :)

------
mahouse
I tried it myself. Most of the bugs that are there explained in that wiki page
aren't really occurring (I guess they were fixed in the meantime), but I
noticed creating and destroying new tabs was much much slower, and that made
me disable it.

~~~
mconley_
e10s engineer here.

There are certainly some performance things to iron out. Right now, we're just
trying to make the base browser functions work properly, and then we'll start
tackling the performance problems.

~~~
mahouse
I know ;)

I'm looking forward to Electrolysis, since having only one process is what
makes me use Chrome: the renderer hangs a lot, especially with complex pages
(such as TweetDeck for me), and when that happens, the whole browser hangs.

------
cpeterso
WARNING! If you run Firefox Nightly to test Electrolysis (e10s), you should
not share your e10s-enabled user profile with other Firefox release channels:
Aurora, Beta, or Release! The Nightly channel has many e10s bug fixes that are
not fixed in Aurora, Beta, or Release.

------
jude-
I'm really glad Mozilla has been working on this. A lot of comments here talk
about UI responsiveness being the key benefit, but another huge win is that it
limits the damage a browser zero-day can do. With this model, a compromised
tab will no longer be able to directly read the contents of other tabs, since
the other tabs live in separate address spaces.

This of course assumes a compromised tab can't go on to compromise the browser
kernel (i.e. the process that manages tabs and shared tab state) or trick the
kernel into giving it unauthorized data from other tabs. However, formally
verifying that a kernel implementation prevents this is feasible in practice
[1].

[1] [http://goto.ucsd.edu/quark/](http://goto.ucsd.edu/quark/)

~~~
pcwalton
> With this model, a compromised tab will no longer be able to directly read
> the contents of other tabs, since the other tabs live in separate address
> spaces.

... assuming those tabs are cross-origin.

> This of course assumes a compromised tab can't go on to compromise the
> browser kernel

Also assumes that a compromised tab can't go on to compromise the _OS_ kernel.

~~~
jude-
> ... assuming those tabs are cross-origin.

Not sure why this has to be a condition. Perhaps tabs loading pages from the
same origin will both have read/write access to some shared data in the
browser kernel (like the site's cookies), but they still run in separate
address spaces regardless. A compromised tab won't be able to directly access
another tab's RAM, as is the case with single-process browsers.

> Also assumes that a compromised tab can't go on to compromise the OS kernel.

Very true. However, my argument was that a multi-process model limits (but
obviously does not eliminate) the impact of zero-days. In the single process
model, the attacker could compromise _any_ tab and have all tab state
available with no additional effort. In the multi-process model, the attacker
would have to compromise the right tab, compromise a different tab and trick
the browser kernel to performing the requisite operations, or somehow bypass
the OS's memory protection. Each of these require more work than before.

~~~
pcwalton
> Not sure why this has to be a condition.

Because they can share JavaScript objects.

~~~
jude-
Sure, tabs can load static assets from a read-only cache instead of re-
fetching everything from the origin (be it an in-browser cache run by the
browser kernel, or a Web cache somewhere between you and the origin). But
surely, the tabs run private instances of the layout engine and javascript VM
when they _process_ the page, no? When would it ever make sense for multiple
tabs to directly access each other's runtime state?

~~~
pcwalton
> But surely, the tabs run private instances of the layout engine and
> javascript VM when they process the page, no?

No.

For example, you can get direct access to another tab's "window" object in
this way, as long as it's same-origin: [https://developer.mozilla.org/en-
US/docs/Web/API/window.open...](https://developer.mozilla.org/en-
US/docs/Web/API/window.opener)

> When would it ever make sense for multiple tabs to directly access each
> other's runtime state?

For Web compatibility.

~~~
jude-
I'm not sure that your example prevents the implementation of per-tab
javascript VMs. Wouldn't the browser be designed such that its kernel mediated
all tab-to-tab runtime state queries? Then, tabs wouldn't directly access each
other's state, and the kernel would interpose security policies (such as same-
origin-only requests) between tabs regardless of a tab's behavior. To keep
this arrangement transparent to programmers, the tab's javascript VM would map
access to shared state (like a window's opener) onto the appropriate call to
the kernel, obviating the need for direct inter-tab memory access while
preserving compatibility.

~~~
justinschuh
Layout and compositing need to be cross-origin; the Web implicitly allows
cross-origin resource loads; and (as was raised above by pcwalton) browsing
contexts like windows and frames need to function as if they're running on the
same thread and can potentially be shared. All of that is to say that all of
the potentially shared state makes it extremely difficult to bind a web origin
to a process for security purposes. It's a hard enough problem that a team of
Chrome engineers has been working on it for a few years, and are only now
approaching an alpha implementation.* And that's many years after Chrome was
entirely multi-process with sandboxed web renderer processes.

* [http://www.chromium.org/developers/design-documents/site-iso...](http://www.chromium.org/developers/design-documents/site-isolation)

------
wjoe
I was wondering about the benefits of this. Supposedly having tabs in
different processes should improve performance of the browser in general, as
slow running scripts in one tab process won't slow down the main UI process. I
have come across this problem before, including the whole browser freezing
from some slow JS. But does this need to be done with separate processes?
Surely running tabs in a different thread to the UI should solve this issue
too?

I'm a bit concerned about the effect this could have on RAM usage and plugin
compatibility - the linked wiki page already lists two plugins that I can't
live without (NoScript and Tree Style Tabs) as being incompatible. Hopefully
that will be fixed before this becomes default in a release.

~~~
cwzwarich
Part of it is probably that browsers use so much shared global data that it is
easier to just make another process. There are also fault isolation and
security benefits you get from splitting the web content into a process that
can have a tighter sandbox policy.

------
notorious1212
I got the option to enable this the last time my Nightly installation was
updated. It's been working well so far, but plugins are leaving a lot to be
desired. On OS X Yosemite, full screen flash video will make the entire
browser crash with the tab. On OS X Mavericks, it looks like the native
Firefox PDF viewer is no longer available, and the adobe plugin was not
working at all in its place.

I'm excited about e10s though, I think this is definitely the right way to go
for all browsers!

------
Animats
"Electrolysis" finally works? Several years ago, Mozilla gave up on it. This
is progress.

Now the question is how tightly locked down the page processes are. Can they
access files? Or is all file and persistent state access via some separate
process? Done right, each page process should execute in a jail, lacking the
privileges to alter external files or persistent state.

------
reubano
This is a main reason I don't use Chrome. Since each tab is running under a
sep process, there is no easy way to tell how much total memory is being used.
Despite all the improvements, Firefox still has some pretty bad memory leaks
and often runs over a gig of memory with just 5 or 6 tabs open. If they go
this route, mem leaks will be harder to spot.

~~~
coldtea
> _This is a main reason I don 't use Chrome. Since each tab is running under
> a sep process, there is no easy way to tell how much total memory is being
> used._

Seeing "how much memory is being used" is a major use case for you using a
browser?

If a browsers works fast and doesn't leak memory, one shouldn't care how much
memory exactly is used.

~~~
reubano
> If a browsers works fast and doesn't leak memory, one shouldn't care how
> much memory exactly is used.

That's a big assumption. Realistically speaking, there's only FF, Safari, and
Chrome. FF leaks like crazy (sometimes on it's own but sometimes it could be a
plugin). Safari doesn't support all the plugins I use and Chrome may but I'm
don't like their dev console layout. And if you don't see how much mem is
being used, you have no way of telling if a newly installed plugin just caused
a memory leak (unless it just totally prevents you from using the browser).

~~~
coldtea
Here's an idea: don't install plugins. They are mostly irrelevant to browsing.

~~~
reubano
I only use plugins that are relevant to my browsing. ABP, Boomerang, Buffer,
DownThemAll, Firebug, NoScript, Wallaby...

------
ksec
Realistically Speaking, I think this is still at least another 6 months to 1
year away from moving to Aurora or Beta Channel.

~~~
asadotzler
I think we'll see it in Aurora sooner than 6 months. Care to wager?

~~~
zz1
Looking forward to it!

------
silon3
Is there a "Ctrl+tab" extension that works properly with this?

~~~
cpeterso
There is an undocumented about:config pref "browser.ctrlTab.previews" that
enables a tab preview switcher. The switcher works with e10s, but not the tab
previews. You can watch e10s bug 863512 for more info:

[https://bugzilla.mozilla.org/show_bug.cgi?id=863512](https://bugzilla.mozilla.org/show_bug.cgi?id=863512)

------
pearjuice
After versioning, functionality and UI they now copy sandbox-mode from the
Chromium project. I don't think there's much time left before you won't be
able to make the distinction between Firefox and Chromium anymore.

~~~
quotemstr
You mean that Chrome copied IE's sandboxing?

~~~
gsnedders
From what I've heard from both Google and MS people, Chrome had it first, it's
just IE announced it (and shipped it in a beta) first. Alternatively, if you
don't want to trust word of mouth — there's no way the Chrome team did their
entire sandboxing implementation in the five months between IE announcing it
and the announcement of Chrome, it's just too much work.

------
blueskin_
Yay, now firefox can waste just as much memory as Chrome. Guess 1GB for the
whole browser wasn't enough; they had to go for ~100MB/tab.

Got to keep up with Chrome after all.</s>

If I use chrome for normal browsing (I don't normally because its feature set
is poor, customisability is a dirty words, and I don't like the privacy risk),
it can rapidly slurp 4GB or more of memory (with perhaps two key addons,
adblock and DoNotTrackMe). Even firefox at its worst rarely if ever goes over
1.5GB, even with very heavy customisation and plenty of privacy/adblocking/etc
addons.

>Performance would improve because the browser UI would not be affected by
poor performance of content code (be it layout or JavaScript).

What about by the overhead from task switching hundreds of processes and
mapping all the memory when each one takes up 50MB or more?

~~~
aen0
Be aware that Adblock Plus for Chrome increases significantly RAM usage for
each open tab.

uBlock author has extensive benchmarks about this issue.

[https://github.com/gorhill/uBlock/wiki/%C2%B5Block-
vs.-ABP:-...](https://github.com/gorhill/uBlock/wiki/%C2%B5Block-
vs.-ABP:-efficiency-compared)

~~~
blueskin_
Whichever one it is for chrome I have, it isn't ABP, it's a generic named
Adblock. I don't use ABP due to the developer accepting money to whitelist
google adverts.

~~~
abrowne
If you don't like that behavior, you probably wouldn't like Ablock's either:
[https://palant.de/2014/07/29/which-is-better-adblock-or-
adbl...](https://palant.de/2014/07/29/which-is-better-adblock-or-adblock-plus)

(Admittedly the author is biased towards ABP. My biases: former Adblock user,
former ABP user, current Adblock Edge and µblock user.)

~~~
blueskin_
Thanks. Probably going to evaluate
[http://alternativeto.net/software/ublock/](http://alternativeto.net/software/ublock/)
instead next time I have to use chrome.

