For Browser Extensions, Grease is the Word

Chrome now has Greasemonkey support. The Chromium patch came from Aaron Boodman, who is at once a Google employee and the brains behind the original Firefox Greasemonkey extension.

It makes me wonder if this is the plan for Chrome add-ons. Forget about anything like Firefox’s add-on mechanism and just rely on Greasemonkey. With the right APIs, it’s all you need.

For a long time, I have been confused and disturbed by the disparity between Greasemonkey and Firefox extensions. Creating a Greasemonkey extension is dead simple for any Ajax developer; creating a bona fide Firefox extension is more complicated, and involves writing the kind of meta-descriptions and JARs that most Ajax folk avoid. (The kind of simplicity mantra that has made JQuery king of the hill for now.)

You might recall I automagically ported the domain teleporter Greasemonkey script to a Firefox extension a while back. That this was possible, and easy, demonstrates that the Firefox extension mechanism could be made a lot simpler. I thought there was talk of doing it for FF3, but it didn’t happen.

What do Firefox extensions do that Greasemonkey can’t? Nothing Greasemonkey can’t get around.

  • Extended access – manipulating the Browser Object Model, accessing local file system, etc. All of this could be possible from a Greasemonkey script with the right APIs available. There are security implications, of course, but as long as users are aware of who can do what, it’s no different from what we have now. It may be even better, due to Greasemonkey’s built-in wildcard-based URL filtering, so that certain apps might only be limited to certain domains.
  • Metadata – certain metadata is present in an extension. This could just as easily be part of Greasemonkey’s metadata.

It’s my hope that Google’s vision for Chrome plugins is Greasemonkey on Steroids, and that this unleashes a whole new ecosystem of powerful add-ons that have until now required too much effort to build.

More Adventures in Firefox Extension Land: Submitting to Mozilla

I recently explained how I created my first Greasemonkey script as an experiment, then converted it to a standalone Firefox plugin/extension/add-on using an automated tool. Official homepage here. The experiment continues, as I subsequently submitted it to Mozilla, and it’s now been approved as an official plugin.

I’ve been curious about the process people go through to submit an official extension, so here’s the rundown.

1. Upload XPI File

Standard upload of the XPI file, which contains all the plugin contents.

2. Provide Metadata

… such as my name, the extension’s homepage, and so on. (Why isn’t this info just packaged inside the XPI file? Actually, some of it is already in that file anyway.)

One interesting thing here is that I get to choose the category it goes in (although I guess the approver could change it later on). Note also that there’s no help about the categories on this page, so I think there’s a large risk that developers will probably be inconsistent. Not bashing Moz about this, but I do think they could make it easier for end-users to locate plugins if they encouraged consistent labelling – I’ve sometimes trawled through 5 or 6 pages trying to find a plugin within a particular category.

3. Wait for Approval

An official Mozilla person must now look it over, which is a reassuring security measure. (Complain all you want about Ajax and its tabloidistically alleged “security holes”, but the open-source nature of web architecture is extremely compelling from a security perspective.)

After about thirty hours, I received an email that the plugin had been approved. And now it’s available from Mozilla, ID 2816.

If you told me I was cluttering up the space of extensions with this trivial 7KB contribution, I’d say you’re probably right, but then what’s the harm in lots of extensions, as long as it’s easy to locate the one you want. (UserScripts.org, the GM repo, does that to great effect with the power of tagging, and a wiki would make it even more useful.) Not everyone wants to set up GM and maintain the scripts, even those who are savvy enough to know about extensions.

In summary, Greasemonkey and associated tools make it easy, bordering on trivial, for anyone with basic Ajax knowledge to create a standalone Firefox extension. Of course, it will be functionally limited to GM-type page munging, but it’s still a lot easier than I had imagined.

Teleporter – From Greasemonkey to Self-Contained Extension

<

p>My previous post outlined Domain Teleporter, a first attempt at a GM script. Continuing the experimentation (as I have a comlpetely different real example in mind), I wanted to see how easy it was to create a self-contained FF extension from the GM script … I figure there’s a significant population who have FF and can’t or don’t want to install Greasemonkey, even if this leads to a functionally trivially extension.

<

p>Converting a Greasemonkey script to a Firefox extension was stupidly simple, thanks to an online tool, Anthony Lieuallen’s User Script Compiler. I’d read about it a while ago, and assumed there must be some catch, but the conversion was indeed child’s play … enter your name and homepage, cut-and-paste the script, and submit. The XPI pops out immediately as a binary download.

<

p>FWIW, the extension is published here; I used htaccess in the distro directory to ensure it will be an installable download (so it can be installed immediately, as opposed to saved locally) as follows:

AddType application/x-xpinstall xpi

The Richer Plugin pattern talks about the importance of FF extensions and the like.

BTW The extension is Amazon Teleporter, not Domain Teleporter, because there’s no longer any way to change the default “Amazon*” domain for which it applies – GM supports that sort of thing as a built-in feature; whereas an extension would have to implement it manually … a lot more work, requiring a custom-made options dialog and a persistence mechanism.

Domain Teleporter – Greasemonkey Script

Update: As an experiment, converted this into a Firefox extension (Blog Article, Extension homepage)

DomainTeleporter, my first Greasemonkey script, is related to this blog post from last April:

If you shop at Amazon.co.uk, you’re often out of luck when it comes to reader comments. So I often find myself editing the URL, switching back and forth between .co.uk and .com. Luckily, this transatlantic adventure usually works out, as the crazy Amazon IDs match.

Domain Teleporter flips the location between .com and .co.uk, retaining the rest of the URL. It would be nice to make it more generic – switch to an (quasi) TLD – but that would require more regexp parsing than was necessary here. Incidentally, I’d like to see a JS library that munges URLs – extract out the domain, the path, etc.

The script is configured to only run on Amazon, but you might find it useful with other sites too, in which case, change the applicable domains using the GM dialog.

Writing the GM script was fairly straightforward, began by copying Mark Pilgrim’s “Hello World”. It’s standard JS for the most part, but there was one gotcha: events don’t usually work with the usual, portable, solution of “control.onclick()” – you get a “component not found” error. You must instead use addEventListener().

Flock: A Tribute to Unusability of Firefox Extensions?

You’ve probably noticed the buzz around Flock, a browser built on Firefox. Information’s limited, but it seems to pick up on the “social” buzzword – tagging, annotations, RSS etc. Thing is, all of these things are possible in Firefox too via extensions. But extensions haven’t really taken off, and the reason is, quite frankly, poor usability. Firefox is a great browser with a plugin architecture that’s pretty good too. The problem is at the last mile: helping users install and manage their extensions.

Sure, developers will install programming extensions and uber-geeks will set up mouse gestures, but it won’t get beyond that in its current state.

So here’s how a plugin architecture should work:

  • Installing plugins should be dead simple. Pull up a list of plugins and click to install … that’s it! Come on, you own the whole browser and the server too! Make them work together. The current task is something like “visit extensionroom, search for extension, jump into extension page, click Install, Notice security dialog box about this subdomain if you’re lucky, Allow the subdomain, Click Install again if you’re savvy enough to realise what just happened, Watch it download, Click Install, Restart the browser if you’re still interested”. If the version’s incompatible, you’ll only find out at the end of all that (except the restart). True, the version number’s shown when you install it, but that’s really making the user do something the computer should do immediately. Also, most users don’t remember what version they’re running, and I’ve even seen extensions with the version labeled as “Deer Park”.
  • The standard distribution should have a set of extensions pre-installed. Just because you’re using a plugin architecture doesn’t mean you have to ship with a bare-bones distribution. I know there are potentially licensing issues, but shipping with plugins seems to work OK for Eclipse and similarly for the Linux distributions. Satisfy the slashdot crowd with a minimal distribution too, by all means, but mainstream users would rather not spend three hours working out how to install extensions, finding out which are popular/useful, discovering incompatibilities between different extensions, etc. There are plenty of extensions that enhance basic functionality – e.g. All-In-One Sidebar, Adblock, the improved search bars, the improved RSS aggregators – why not take advantage of them? In addition, there’s great scope for specialised distributions, e.g. Developer, Socialite. I know anyone could probably make them and distribute them, my main point here is that Firefox itself should at least distribute a more powerful default distro.
  • Don’t rely on third-party extensions for fundamental functionality. Tabbed browsing works OK in the basic distribution, but the Tabbrowser extension gives it much more power – certainly it brings it up to Opera standard. Yet, it’s been unsupported for over a year, confusing, and buggy at times. Something like this is too important to leave to a third-party. Develop it as an extension if it’s architecturally convenient to do so, but make it mandatory, so that other extensions play nice with it.
  • Provide update notifications. Indicate when updates are present and offer to do the update automatically.

Greasemonkey took off so quickly because it’s so easy to develop, modify, and install GM scripts. Hopefully, the lessons of Greasemonkey and the imminent release of Flock will offer some lessons, and help make Firefox an even greater browser.

Greasing Greasemonkey Scripts

Tweaking a Greasemonkey script is easy. It’s just a single file, so you download the file locally, edit it, and install it the same way you’d install any other script.

I did this because I needed a quick fix for the super-helpful XMLHttpRequest Debugging script. Sometimes the console has a little trouble with positioning – using it with Google Maps caused it to sit behind the upper portion of the page due to layering. So I made two quick fixes – increased the z-index in the embedded stylesheet so it would appear in front and also changed the default coordinates (I’d adjusted them with “about:config”, but somehow that wasn’t picked up.)

All in all, I was able to tweak the script, not knowing anything about the GM API, and have it running in my browser in about 10 minutes. Had it been a standard Firefox extension, I would have been out of luck. I’d presumably have to download the original source, set up a dev/testing environment, and be able to package it all up including meta-info. Furthermore, I’d have to restart Firefox to test it, unlike Greasemonkey which works straight away. I’ve never tried all that with extensions, but that’s my perception from a little looking around.

I’m nowhere near as bullish as some about Greasemonkey, at least in the medium-term, as some people, because I think the whole Firefox extension mechanism is way too complex for most end-users, let alone the idea that you have to install Greasemonkey scripts on top of one of those extensions. But in any event, once you have the Greasemonkey extenstion installed, it’s a cinch to remould a script you come across.