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?

[edrex]

Also thanks @ChimeraCoder, @kevincox for the helpful responses.

[gkatsev]

Starting from scratch is both good and bad. It gets rid of a lot of cruft that the current code base has but it also means that there's probably features that we're losing just because we don't really remember they exist. At the same time, maybe we don't need those features?
In addition, a brand new implementation at this time is kind of stuck in a weird place since the XPCOM APIs that we're relying on right now are being deprecated and the new WebExtensions API have nowhere near the feature support that vimperator requires to function and have feature parity.

Possibly the best option is to have @ChimeraCoder coder help out port the existing code to e10s based on his learnings from starting from scratch? I'm finally going to have more free time again to dedicate to this project and e10s is almost at the top of the list (the top item is to just get vimperator working in nightlies with e10s disabled).

[edrex]

In addition, a brand new implementation at this time is kind of stuck in a weird place since the XPCOM APIs that we're relying on right now are being deprecated and the new WebExtensions API have nowhere near the feature support that vimperator requires to function and have feature parity.

This reminds me of a joke from a Googler about all Google APIs being either deprecated or experimental. I guess funny since e10s is Chrome inspired.

I may try to make some PRs on electrovim to get up to speed so I can help with Vimperator port later.

[ChimeraCoder]

@edrex To clarify any confusion - my goal isn't to fork the community. I'm a longtime Vimperator user, and I created Electrovim in May because I realized after two months of e10s that I just couldn't live without Vimperator's basic features! I put it up on AMO because a few of my colleagues felt the same way.

As I mentioned, I started with a clean slate out of convenience as someone with no experience with the Vimperator codebase. If Electrovim can be helpful in that, that's great.

@gkatsev I'm happy to share my lessons learned from Electrovim, since it took a couple of different approaches to find one that works. I'll preface that by saying, though, that I don't really have any experience with the XPCOM/XUL APIs, though.

Also, I'd be remiss if I didn't mention again - thanks again for an extension that's been an indepensible part of my browsing workflow for years!

[ChimeraCoder]

Also, @gkatsev, just FYI - the Mozilla devs are starting to host periodic office hours on e10s in case that's helpful: https://atsay.github.io/e10s_office_hours/

[gkatsev]

@ChimeraCoder thanks! Saw that earlier today. I'll probably try and plan to do something with that and of course any of your help would be super helpful.

[maxauthority]

@aditya Mukerjee: It's good to see some work on a vim-inspired add-on with
supports both e10s and also seems to be in the new WebExtensions format
without dependencies on XUL. Probably starting "fresh" and incrementally
adding back features is a good idea. Although I might suggest you also take
a look at Vimium for Chrome which should be possible to port (hopefully
easy) to "new" Firefox, and which already has many features writen in a
non-XUL dependent way (although I am not sure if they are depending on
chrome only features or it should be mostly compatible with Firefox
WebExtensions).

On Wed, Nov 25, 2015 at 10:20 PM, Gary Katsevman notifications@github.com
wrote:

@ChimeraCoder /~https://github.com/chimeracoder thanks! Saw that earlier
today. I'll probably try and plan to do something with that and of course
any of your help would be super helpful.

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

[mrf]

There is already a Firefox clone (more or less) of Vimium which supports e10s. Could be another source of inspiration.

akhodakivskiy/VimFx#378

[marcdeop]

I recently saw https://bugzilla.mozilla.org/show_bug.cgi?id=1100918 .

Is there any work being done on this? I can't seem to find any related commit...

[gkatsev]

@marcdeop ah, cool. Didn't know about that. No, unfortuantely, no work has been done yet. Hope to be able to begin soon.

[vityas-off]

Hi. Has there been any progress on this issue?
Recently tried firefox 49 build and it is extremely fast, feels like hardware update. But unfortunately vimperator is the only dealbreaking issue for switching now.

[ErikBjare]

I would also like to switch to Firefox 49 asap, trying e10s out in FF 48 led to some issues. I'm assuming no one is working on this?

[timss]

There's no dispute regarding the importance of e10s support in Vimperator, it is indeed essential for the future of this addon and not a question of priority. But this requires dedicated contributors that are up for the task and with time on their hands, which unfortunately isn't readily available at the moment.

New (and returning) contributers are always welcome and encouraged, so if you feel like having a go at the code please feel free! While comments of support are nice, what is required is actual code being produced. Vimperator is and needs to continue to be a community effort to succeed.

Furthermore there's the elephant in the room with the deprecation of XUL in favor of WebExtensions. It is not clear what this means for Vimperator yet, leading to a bit of limbo.

It could be that the most straightforward option is adding e10s support to the current code base and tackle WebExtensions later, or maybe it's better to start from scratch with WebExtensions and add features as time goes. Both are considered possible solutions at this point, and depends on what is contributed.

[SammysHP]

By the end of 2017, and with the release of Firefox 57, we’ll move to WebExtensions exclusively, and will stop loading any other extension types on desktop. To help ensure any new extensions work beyond the end of 2017, we’ll stop accepting new extensions that are not WebExtensions in Firefox 53.

https://blog.mozilla.org/addons/2016/11/23/add-ons-in-2017/

That sounds like a death sentence for Vimperator.

Firefox 57 is planned for 28th November 2017
Firefox 53 is planned for 18th April 2017

[vityas-off]

I'm using VimFx since firefox 49. Its pretty good, but lacks vim-like UI. Maybe a good idea is to make only UI addon and use it in pair with VimFx.

[timss]

Thanks for sharing, @SammysHP. Quite "ambitious" of Mozilla.

[ghost]

@timss maybe you replace vimperator's code with code from cvim (chromium vim)? It's has commandline, statusline and other vimperator's features, not all of course. And it's under MIT license.

[soredake]

or vimium /~https://github.com/philc/vimium or /~https://github.com/jinzhu/vrome or /~https://github.com/k2nr/ViChrome

[SammysHP]

@stepshal @soredake How would this help? You could use other extensions if you want. Simply using all of their code (and thus duplicating/forking the extension) won't help. And you cannot simply take code from program A and put it into program B and everything works.

[kevincox]

Also I tried switching to chromium and using both vimium and vichrome were very unreliable. Vimperator has worked consistently for me and that's why I have been using it. OTOH I have been trying VimFx recently and it has been working very well.

[ghost]

@soredake Vimium is just like Vimfx from Firefox, we need commandline.

@SammysHP cVim doesn't work in Firefox as it is, it's need to be modified, but maybe current WebExtensions APIs in not enough.

[MPW1412]

Is there anyone working on the adaption of vimperator to the new api? Firefox 57 isn't that far away anymore.

[chocolateboy]

@MPW1412 #705

[SammysHP]

With FF 55 Nightly the support for non-e10s addons was disabled.

[iblislin]

Hi, I have 3.16.0 and e10s is enabled.
When I hit @, got the error: "TypeError: 'preventDefault' called on an object that does not implement interface Event."

[SammysHP]

Nope, e10s cannot be enabled together with an addon.

[iblislin]

@SammysHP I force enabled e10s.
And... I just want to help for addressing issue.
What kind of inforamtion is helpful for development?

[maxauthority]

@Iblis Lin: Unfortunately, information alone is is not sufficient to get Vimperator running in e10s. Especially now that XUL-based add-ons are gone soon, only a full rewrite as an WebExtension can save Vimperator :(

…

On Sat, Jun 17, 2017 at 8:30 PM, Iblis Lin ***@***.***> wrote: @SammysHP </~https://github.com/sammyshp> I force enabled e10s. And... I just want to help for addressing issue. What kind of inforamtion is helpful for development? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#211 (comment)>, or mute the thread </~https://github.com/notifications/unsubscribe-auth/AFtBrw50snqr4ptQTLbuUKmwccQielQrks5sFBtYgaJpZM4D2vPv> .