Making new code be electrolysis-compatible

[Bill McCloskey]

Hi everyone,

We're making a lot of progress converting Firefox frontend code to be compatible with multiple processes. One thing that would really help the process along is to agree that new code should be written from the start with electrolysis in mind. That means that anything that touches content data (the DOM, the docshell, or the content inner/outer windows) needs to do so via a content script [1].

People are doing this already; it's really nice to see more and more stuff going in browser/base/content/content.js. (Perhaps we can declare the electrolysis project as officially done when content.js gets as big as browser.js :-) I only bring it up because, a few weeks ago, MattN asked me how serious we are about not landing stuff that breaks e10s. I talked to Gavin today, and he thinks we should be serious about it. So if you're writing or reviewing code that looks problematic, please fix it/ask for changes. If you have any questions, please ask someone in #e10s. Also, it's usually pretty easy to test by running with browser.tabs.remote = true.

Thanks,
Bill

[1] https://developer.mozilla.org/en-US/docs/The_message_manager
_______________________________________________
firefox-dev mailing list
firef...@mozilla.org
https://mail.mozilla.org/listinfo/firefox-dev

[Chris Peterson]

On 12/9/13, 6:42 PM, Bill McCloskey wrote:
> We're making a lot of progress converting Firefox frontend code to be compatible with multiple processes. One thing that would really help the process along is to agree that new code should be written from the start with electrolysis in mind. That means that anything that touches content data (the DOM, the docshell, or the content inner/outer windows) needs to do so via a content script.

For more information, check out Tim Taubert's (2011) blog post [1] about
using message manager and Bill's recent blog post [2] for more e10s
implementation details.

[1] http://timtaubert.de/blog/2011/08/firefox-electrolysis-101/
[2] http://billmccloskey.wordpress.com/2013/12/05/multiprocess-firefox/


chris

[Lawrence Mandel]

----- Original Message -----
> Hi everyone,
>
> We're making a lot of progress converting Firefox frontend code to be
> compatible with multiple processes. One thing that would really help the
> process along is to agree that new code should be written from the start
> with electrolysis in mind. That means that anything that touches content
> data (the DOM, the docshell, or the content inner/outer windows) needs to do
> so via a content script [1].
>
> People are doing this already; it's really nice to see more and more stuff
> going in browser/base/content/content.js. (Perhaps we can declare the
> electrolysis project as officially done when content.js gets as big as
> browser.js :-) I only bring it up because, a few weeks ago, MattN asked me
> how serious we are about not landing stuff that breaks e10s. I talked to
> Gavin today, and he thinks we should be serious about it. So if you're
> writing or reviewing code that looks problematic, please fix it/ask for
> changes. If you have any questions, please ask someone in #e10s. Also, it's
> usually pretty easy to test by running with browser.tabs.remote = true.

Is it much more difficult to write e10s compliant code? (Sounds like the answer is no.) How much extra work (if any) do you expect this to be for the average front-end engineer?

Lawrence

[Bill McCloskey]

----- Original Message -----
> From: "Lawrence Mandel" <lma...@mozilla.com>
> To: "Bill McCloskey" <wmccl...@mozilla.com>
> Cc: firef...@mozilla.org
> Sent: Tuesday, December 10, 2013 5:13:43 PM
> Subject: Re: Making new code be electrolysis-compatible
>
> Is it much more difficult to write e10s compliant code? (Sounds like the
> answer is no.) How much extra work (if any) do you expect this to be for the
> average front-end engineer?

I would be surprised if writing a completely new feature took much more work when done in an e10s-compatible way than in an e10s-incompatible way. In my admittedly limited experience, most frontend code doesn't touch content at all. For those features that do touch content, they don't do it too much, and the extra work when they do is pretty minimal. When we've rewritten code to be e10s-compatible, I don't think the result has been much longer (in lines of code) or harder to debug than the original. That suggests it wouldn't have been harder to write it the e10s way than the original, although it's hard to quantify any of this.

There are exceptions, of course. Occasionally we end up ping-ponging back and forth between chrome and content a few times in order to get work done, and it can be a little ugly. However, I've only seen this a few times, and I don't think it's any different than some of the callback-heavy code we have when going to disk.

Despite all this, I think there's little doubt that it's more work to write code in an e10s-incompatible way and then have to fix it later to be compatible. That's why I think it makes sense to try to do things right from the start. If there are concerns about a particular feature being too hard to write in e10s, then we should of course talk about the trade-offs. But I think the most sensible *default* policy is to write code that's electrolysis-compatible.

-Bill

[Gavin Sharp]

On Mon, Dec 9, 2013 at 6:42 PM, Bill McCloskey <wmccl...@mozilla.com> wrote:
> We're making a lot of progress converting Firefox frontend code to be compatible with multiple processes. One thing that would really help the process along is to agree that new code should be written from the start with electrolysis in mind. That means that anything that touches content data (the DOM, the docshell, or the content inner/outer windows) needs to do so via a content script [1].

I concur. All Firefox reviewers should treat this as a requirement
when reviewing new code. If we identify specific cases where following
this policy is overly arduous, they should be discussed here on
firefox-dev, but I don't expect there to be any such cases.

Gavin