vimperator-labs
vimperator-labs copied to clipboard
vimperator
Add support for e10s (electrolysis)
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).
It would be indeed a nice addition :-)
Would be willing to test nightlies for this...
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.
- 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".
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.
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 < [email protected]> 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 https://github.com/vimperator/vimperator-labs/issues/211#issuecomment-98255797 .
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.. :(
I definitely will work to fix any issues, particularly if they affect me directly :). e10s support will come. The question is how soon :D
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.
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).
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.
@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
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.
@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?
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).
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.
@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!
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/
@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.
@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 [email protected] 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 https://github.com/vimperator/vimperator-labs/issues/211#issuecomment-159733912 .
There is already a Firefox clone (more or less) of Vimium which supports e10s. Could be another source of inspiration.
https://github.com/akhodakivskiy/VimFx/issues/378
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...
@marcdeop ah, cool. Didn't know about that. No, unfortuantely, no work has been done yet. Hope to be able to begin soon.
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.
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?
Surely this is a top priority now? If it is not implemented before the next release of Firefox, Vimperator will not be compatible with Firefox. All operating systems get the latest version of Firefox, no matter how stable, so nobody using default package repos will be able to use it without disabling Firefox's latest feature.
@corkybeta Between Mozilla's deprecation of their older extension API and the slowness of Vimperator adding e10s support I imagine it's not fully feasible without what is essentially a rewrite.
@wldcordeiro I agree that a full rewrite seems like it will be necessary. I know that WebExtensions is not fully mature yet. However, I have to imagine that there are some working at Mozilla who use Vimperator would be interested in helping out. (Note, this is full speculation on my part.)
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.
