Add support for e10s (electrolysis)

[ChimeraCoder]

Electrolysis (multi-process Firefox) is now enabled by default in Firefox Nightly (v39), and is being targeted for stable release later this year.

Currently, Vimperator does not work at all with e10s. A few examples of the bugs which render it unusable in Firefox 39 include:

• The settings (liberator://help/options) cannot be opened at all when e10s is enabled
• Insert mode is broken - clicking inside an input field does nothing, which means all input is essentially broken (I am writing this comment with e10s disabled).
• Find (/) is broken

I'm filing this ticket as I've been a longtime user of Vimperator - it's a must-have extension for me - and I couldn't find any other reference to e10s on the issue tracker except in a comment on an unrelated issue (#87).

[marcdeop]

It would be indeed a nice addition :-)

Would be willing to test nightlies for this...

[gkatsev]

Yep, this needs to happen. I'll try and get to that soon.

[gkatsev]

Things people can do to help:

• enumerate specific issues that vimperator has with e10s. @ChimeraCoder has already started that list above
• use the "Browser Toolbox" to figure out where specific breaks in the code are.
• test nightly builds once we have started on this work.

[kini]

• A bunch of navigation keys result in "TypeError: win is null", including PgUp, PgDn, Shift+SPC, C-d, C-u, j, k, gg.
• No follow hints appear on any page when you type f.
• Y results in "TypeError: frame is null".

[wldcordeiro]

E10S issues

• The settings (liberator://help/options) cannot be opened at all when e10s is enabled
• Insert mode is broken - clicking inside an input field does nothing, which means all input is essentially broken (I am writing this comment with e10s disabled).
• Find (/) is broken
• A bunch of navigation keys result in "TypeError: win is null", including PgUp, PgDn, Shift+SPC, C-d, C-u, j, k, gg.
• No follow hints appear on any page when you type f.
• Y results in "TypeError: frame is null".

@ me if you find others and I'll add them. Making them checkable will also help the dev team out.

[maxauthority]

It seems, e10s support will be indeed a pain in the a**, especially given
the limited developer resources we have currently. I am fully in favor of
e10s in general in Firefox, but it might cause real troubles for
Vimperator's future. Hopefully, many of the issues will go away
"automatically" once e10s matures in Firefox itself.

OTOH, rethinking/reworking Vimperator especially for e10s Firefoxes might
also give us a chance to strip some unneeded features, but your list above
is actually quite the core features of vimperator (navigation keys, hints,
find, ...) :(

On Sat, May 2, 2015 at 12:32 AM, Wellington Cordeiro <
notifications@github.com> wrote:

E10S issues

• The settings (liberator://help/options) cannot be opened at all
  when e10s is enabled
• Insert mode is broken - clicking inside an input field does
  nothing, which means all input is essentially broken (I am writing this
  comment with e10s disabled).
• Find (/) is broken
• A bunch of navigation keys result in "TypeError: win is null",
  including PgUp, PgDn, Shift+SPC, C-d, C-u, j, k, gg.
• No follow hints appear on any page when you type f.
• Y results in "TypeError: frame is null".

@ me if you find others and I'll add them. Making them checkable will also
help the dev team out.

—
Reply to this email directly or view it on GitHub
#211 (comment)
.

[ChimeraCoder]

The e10s APIs are mostly stable at this point, with one notable exception (which I don't believe applies to Vimperator). The current breakage is due to Vimperator's use of the old API, so I wouldn't expect any of the above issues with the current Vimperator build to be resolved by Firefox between now and e10s's eventual debut in stable.

I agree that upgrading to the new API is going to be a significant amount of work, which is why I filed this ticket now. It might seem like e10s in stable is a long way off, but that date will come a lot faster than we think. If Vimperator doesn't have at least basic support for e10s by then, the best-case scenario is that it will be included in the Firefox add-ons blacklist that is shipped. The worst case... well, I don't want to think about that.

The good news is that, at least under my understanding of Electrolysis, the core functionality should already be possible to port to e10s. There are a number of other extensions which provide somewhat similar functionality to Vimperator's that have already been ported, so I'm optimistic that it will be feasible.

I know that this will require time and effort, but I, for one, have been using Vimperator for so long that I can't imagine browsing without it, and I would be very sad if using Vimperator meant having to run older or unsupported versions of Firefox that don't have the latest security patches, etc.. :(

[gkatsev]

I definitely will work to fix any issues, particularly if they affect me directly :).
e10s support will come. The question is how soon :D

[ChimeraCoder]

That's great to hear - thanks for clarifying. :)

Just a quick update - the latest version of the developer edition of Firefox was released this week (40.0.a2). It's the first non-nightly version to contain e10s and prompts the user to enable it when first loaded after the update. Hopefully this will help expand the development/testing base here.

[dannyob]

e10s is now on by default in Firefox Developer Edition (which I think maps to a "beta" channel -- it's Firefox 42.0a2 (2015-08-16)). I'm still seeing these problems with Vimperator 3.10pre -- it means you have to disable either Vimperator or e10s immediately or have problems entering anything in forms (ie in insert mode, which is broken).

[edrex]

It seems like it's important to get started on this sooner rather than later, lest Vimperator get marooned on old Firefox. I don't have experience developing Firefox addons, but I feel committed to using Vimperator and would be willing to help with a port.

I think the first step would be for someone to take a crack at getting basic functionality working in a branch, and in the process validate that Vimperator's functionality can be updated to work with the add-on API changes.

I don't know the best way to handle the need to continue supporting both environments. It may be necessary to have the extension probe the environment at runtime and conditionally load different implementations. If the new APIs are available in the old environment then maybe it's not a problem. Otherwise perhaps there is a facility to ship different builds to different browser versions.

Once a branch is available with a first pass at e10s support, a project owner could create a milestone to track e10s compatibility issues.

[ChimeraCoder]

@edrex For what it's worth, I took a stab at getting the basic functionality working under e10s, though I started from a clean slate: https://github.com/ChimeraCoder/electrovim

If I remember correctly, a number of the SDK features that Vimperator currently uses are deprecated under e10s, which makes it difficult to try porting piece-by-piece. (There's a separate problem, which is that a number of the ones that aren't deprecated are still synchronous, though this is an issue that Firefox says they are working on.)

To answer your other question, extensions that work under e10s using the high-level SDK APIs are backwards-compatible; the challenge would be in porting Vimperator to use only the high-level APIs (and/or to test any low-level APIs used to ensure e10s compatibility): https://developer.mozilla.org/en-US/Add-ons/SDK/Guides/Multiprocess_Firefox_and_the_SDK

[kevincox]

I'm not an expert on e10s but I have some Mozilla experience and have loosely followed it.

Basically the "new" API's have been around for quite a while in preparation and have been recommended for quite some time. I don't know how vimperator is written but the best action plan is probably moving completely away from the depreciated APIs. I don't expect that there will be problems supporting relatively recent versions of firefox in this way.

[edrex]

@ChimeraCoder great to know there's a start of a Vimperator-alike using the high-level APIs. I'm of two minds:

• switching APIs seems like an excellent opportunity to start with fresh code.
• forking the community with a new project seems unfortunate, since Vimperator has a very mature user base.

@gkatsev @maxauthority, what are your thoughts on a ground-up reimplementation vs patching the existing codebase? If Electrovim were brought to feature parity would releasing a new Vimperator based on it be an attractive option?