Vimperator, Vimium and the switch to Qutebrowser

Much to the chagrin of anyone that uses a web browser on my PC, with particular apologies to my girlfriend, I’ve been an enthusiastic user of Vimperator for several years. Vimperator is a Firefox extension that turns it into a keyboard-driven browser, one that behaves much like the text editor Vim. Unfortunately, Mozilla has deprecated the XUL extension API that vimperator and many legacy extensions depend on, in favour of the web extension standard pioneered by Google with Chrome.

I can understand why they made this change. Legacy extensions are a large source of pain, can pose a security risk to host systems, and make invasive, sometimes unstable changes to the behaviour of the web browser. Mozilla often took flak from users for poor performance caused by poorly-written extensions, which were sometimes installed without the users’ knowledge or consent (Skype click to call extension, I’m looking at you).

What’s more, XUL extensions are partly responsible for the slow roll-out of their multiprocess implementation, called Electrolysys.

All this probably explains why Mozilla decided to adopt Google’s extension standard, and drop XUL. Unfortunately, Vimperator, a volunteer project, looks as though it will be a casualty of this decision, and it is highly likely that it never work after the legacy extension APIs are removed in Firefox 57.

So with Vimperator effectively dead, what’s a Vim user to do?


There’s a Firefox port of the Chrome Vimium extension to Firefox, called vimium-ff. I’ve installed it, and it works, most of the time. However, there are some significant problems with Vimium that are inherent to using web extensions for UI plugins. Specifically, that they can’t really do a lot to alter the user interface!

Vimium works by injecting keyboard shortcuts and its UI elements into the web page. For some functions, such as navigating links (by typing a capital F), this works great. The problems become clear when you try to do something before the page has loaded; the shortcuts aren’t active yet.

Other problems include:

  1. UI elements such as the command bar appear within the web page rather than surrounding it; everything has to happen within the content frame.
  2. Some parts of the user interface, such as the new tab page and preference pages, aren’t modifiable by extensions (in the case of the new tab page you can work around this with a separate plugin to change it to about:blank, and then the Vimium shortcuts will work).
  3. Related to (2), relying on the traditional UI at some points means you can’t hide traditional UI elements such as the address bar.

The authors of a potential Vimperator reimplementation called tridactyl have documented the problems in much more depth than I ever could here, but overall the web extension standard doesn’t seem sufficient to support plugins that significantly alter the user interface. Given the inherent conflict between permissive APIs and security, I doubt this will change any time soon.


Qutebrowser sidesteps the above issues, because it’s a totally separate web browser which defines its own user interface, but it does come with its own set of trade-offs.

  1. You can’t use other Firefox/Chrome/Web extensions, in fact there is no support for plugins (although support for Python-based plugins is planned).
  2. As a result of (1) there is no ad or tracking blocker, other than a rudimentary built-in hosts-file based blocker, which isn’t very effective.
  3. It lacks much of the polish and easy configurability of mainstream browsers (for people who like text-based configuration files, this can actually be a plus).

The main difference that I’ve noticed from Vimperator is that it more strictly adheres to the idea of a modal browser. Vimperator would automatically enter insert mode on opening a new page. With Qutebrowser, on opening a new tab with you’re still in command mode, despite the blinking cursor in the search box. If you press any keys you’ll be entering commands, not typing letters, so you have to enter insert mode first. This is more like Vim, and thus exactly how it should be, but less like a web browser, and thus could be jarring for new users. Emacs or non-vim users looking for a keyboard-driven browser should probably look elsewhere.

I’ve used it for about a week, and it’s become my main browser. It’s not perfect, and I’ve noticed the occasional glitch, but it does at least seem to support process separation – I can see a new QtWebEngineProcess start-up for each tab. This is more than could be said for Vimperator on Firefox! It also seems to use less memory than Chrome for the same page (not a high bar to clear, granted).

Overall, I’m impressed so far. If you’re a Vimperator or Pentadactyl user I highly recommend giving Qutebrowser a try. If you’re a happy Vimium user, also give it a go, but you may find it takes things too far.

5 thoughts on “Vimperator, Vimium and the switch to Qutebrowser

  1. William

    Seems like an awful lot to give up for a set of keybindings… I’ve been using chrome’s cVim. Not a perfect experience, but functional enough. Agree about the modality being annoying, but a browser has so many different mental contexts that the modes should be separate IMO

  2. Alex Forbes Post author

    It’s much more than a set of keybindings! This is the whole user interface we’re talking about. Next you’ll be telling me that the CherryMX Blue switches on my mechanical keyboard are just buttons. 😝

    I just tried cVim, and it’s more complete than Vimium, but has no Firefox version yet that I can see. It still suffers from the restricted API of web extensions though, namely that the whole experience breaks when you open a new tab or do anything outside the context of a web site.

    Regarding the insert mode on load, the default insert behaviour makes sense to me, it’s just that my Vimperator-trained muscle-memory had me typing in the search box immediately. So I’d rather get used to it than change the default.

    Thank you both for the replies!

  3. William

    A windows-only solution might be to use autohotkey… But I’m not sure what limitations you’d end up with down that route.

  4. Anjan

    I kinda followed the same path, but ended up using lua-kit instead of Qutebrowser, though i had given it a try, i liked lua-kit better.


Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.