The Chrome team launched a new beta today, for the first time supporting MacOS X, Linux and Extensions. This work represents the culmination of over a year of work by a large group of folk and I’m very proud of what the team has accomplished. I want to take the opportunity to talk a little bit about extensions.
The Chrome extensions API provides users and developers with the ability to customize the browser while adhering to the Chrome core principles of speed, stability, security and simplicity.
Google Chrome extensions:
- run in their own processes so any potential issues cannot take out the entire browser.
- built using web technology have a restricted API surface and are run within the same sandbox as browser tabs.
- use the same automatic update system as Chrome itself, allowing developers to easily deploy new versions of their software and users to keep up to date with the latest, greatest and safest versions without having to do anything.
You can watch videos about Google Chrome extensions here.
I’ve been working on browser stuff for a while, and people sometimes find my stories interesting, so here’s a little extensions history…
Years ago, when Netscape was building Netscape 6 (its suite of browser, mail, page editor and IM client), a product requirement was that it be possible to install the browser with or without any of the “optional” components - mail, IM, editor, etc. When you installed those components “extra bits” (menu items, toolbar buttons, etc) would appear in the browser UI allowing you to launch mail, IMs, etc.
The Netscape front end was implemented in XUL, a cross platform UI language. The optional components specified things called “overlays” that allowed them to add in their “extra bits” when they were present. The optional components packaged these overlays and the other bits of their logic into “XPI” files that were installed by the install engine.
A few years later, Netscape’s successor Firefox was growing in popularity and developers were discovering that it was possible to use this component install mechanism to add other functionality to the browser. It was never really designed for consumption outside of Netscape’s own product and so not much thought had been given to what APIs should be exposed within the browser UI. It was really an internal API. So when people began making these “extensions” for Firefox, whenever Firefox changed it was possible for the extension to prevent the browser from starting. In the early days of Firefox, it wasn’t uncommon for a user who had an extension installed to see the error “no XBL binding for browser” when they upgraded to a new verison of Firefox.
It became clear that we’d have to fix this before Firefox could reach 1.0, so I put together an extension manager that offered a less hacky install/uninstall path and more importantly added versioning. Given the lack of stable APIs, the system would simply disable extensions not advertised as being compatible with the current version of the browser. This meant developers would have to certify their extension with every new version of Firefox. It wasn’t perfect and was somewhat cumbersome, but it worked, and didn’t require us to freeze a bunch of APIs which we most certainly would have botched if forced to do it in haste.
Firefox extensions have always been a double edged sword - they offer immense flexibility at the cost of forcing developers to re-certify with every browser update. When developers are late to do so, users that upgrade quickly have to do without their extension for a while, or disable the compatibility verification step at their own risk.
I think this historical note is more than just interesting for anecdotal value. If this “back door” into browser customization hadn’t existed by virtue of Netscape’s componentized install, it’s not necessarily a given that Firefox would _ever_ have had extensions. Think about that. It’s awesome that it did, because it’s a feature users love. Because it did, and because users love extensions, now we on the Google Chrome team have the luxury of developing a new API from scratch that represents what we hope is the best of both worlds - customization and Chrome’s core principles.
The Firefox experience was immensely valuable. I am not one of the engineers that has personally done a lot of work on extensions in Google Chrome, but I have enough battle scars to have some thoughts about how they should function. I am really pleased with the approach the Chrome extensions team has decided to take, and so kudos to them for getting us to this first milestone!