blogstrapping

Vimium and Other Chromium Extensions

Last night, I decided to tackle learning how to write extensions for the Chromium browser. Writing extensions is something I never bothered learning how to do for Firefox, over something like seven years -- since before it was called Firefox, and even before it was called Firebird. Part of the reason for this is that by the time I started getting really interested in extensions there were far more of them than I had time to explore, and every time I thought of something I'd like an extension to do, there was already an extension for it.

In my (somewhat limited) experience using it on MS Windows, I quickly came to appreciate Chrome's design, and like it a heck of a lot more than any other browser on that platform. Since before Google first announced its Chrome browser, and released the open source Chromium project in 2008, I have been at least one step ahead of it in operating system selection until very recently. Chromium finally made its way into the FreeBSD ports system as a stable piece of software. Because FreeBSD has been my primary OS of choice for a while now, that means that the opportunity to migrate to Chromium as my primary browser has not really existed before this.

Even now, however, I have run into some problems switching to Chromium. You may note, if you read that article, that one of the major hang-ups is the lack of a good vi-like keybindings extension for Chromium that works on FreeBSD. I had high hopes for Vimium, but ran into some problems with getting it installed.

Last night, I was prompted to look into extension development for Chromium because of this problem. I got at least far enough to figure out some of what's going on with Vimium, and plan to learn more about extension writing for Chromium as well. Thanks to my investigations, I have figured out how to "fix" Vimium to get it to install on Chromium, and am now much happier using the browser on FreeBSD, but I have come to realize that Vimium is certainly not perfect. The Vimperator extension for Firefox is still clearly superior in a number of ways. Vimium, at least, should make using Chromium for a lot of tasks much more tolerable, though I do not know if I will find that enough to make it my primary browser any time soon. We'll see, I guess.

"Fixing" Vimium

The actual Vimium bug on FreeBSD appears to be something wrong with Chromium on FreeBSD, and not a problem with Vimium per se. Chromium extensions can be written using a pattern matching configuration to select which URLs loaded in the browser can be affected by the extension. The pattern matching system is quite simple, and allows matching of URL schemes, domain names, and path names, with very rudimentary support for wildcards. A special pattern, <all_urls>, can be used to match everything that Chromium will let you match.

Unfortunately, for some reason it appears that anything that does not specify a particular URL scheme (such as http://) will not work on my FreeBSD install of Chromium, and I know of at least one other person -- Sterling Camden -- who has run into the same error when trying to install Vimium. It was through trial and error that I was able to figure out what does work in Vimium on FreeBSD.

By default, there was a line in the extension's manifest.json file that contained this code:

"matches": ["<all_urls>"],

In order to get it to install, I have had to get the extension from the Vimium project at GitHub (using git to clone the repository, naturally), then edit that code on my local copy. The new version looks like this:

"matches": [
  "http://*/*",
  "https://*/*",
  "ftp://*/*",
  "file://*/*"
],

As far as I've been able to determine so far, the only way to get Vimium to install on FreeBSD is to specify every URL scheme you want it to match -- and, of course, you can only specify those URL schemes that Chromium will allow. My investigations thus far lead me to believe that http://, https://, ftp://, and file:// are the only URL schemes that Chromium extensions can support, so I've specified all of them. Note, by the way, that a trailing comma on the last list item is invalid syntax, and will make the extension unloadable in Chromium, so if you copy this code you should not add a comma after "file://*/*" in the manifest.json file.

(Note: Once you have the source for the Vimium extension modified on your local machine, you can install it from the local source by following instructions on the Tutorial: Getting Started (Hello World!)) - Google Chrome Extensions page. You can quickly find the snippet of instructions you need by doing a text search on that page for the words "load the extension", if you do not want to take the time to learn how to write a simplistic extension.)

It is my suspicion that this problem is particular to the FreeBSD version of Chromium, or perhaps to the Linux version as well (from which the FreeBSD version is derived). Because of this, I doubt I will submit a patch to the maintainer of the Chromium extension himself, since the correct way to handle broad URL support is surely the way he handled it, and not the way I did. I only did this because the "correct" way is apparently broken in the FreeBSD port of Chromium.

Imperfect Vimium

There are other problems with the Vimium extension, at least on my FreeBSD install:

I have probably run across other issues as well, and forgotten. I may add to this list later if I remember them or discover more gotchas. I will see about reporting bugs to the appropriate parties as I figure out what exactly to report, and to whom.

Addendum: The Vimium Issue

I accidentally stumbled across something in Google's tutorials for extension building that led me to a page where it was indicated that the <all_urls> URL scheme wildcard was added in Chromium 6. A few minutes' investigation later, and I discover that though the stable version is 7.x, the FreeBSD ports maintainer has not committed anything later than 5.0.x, which would explain why I had to use that clunky URL schem list to make the extension installable. Hopefully the port maintainer is actually planning to commit a new port soon.