While I’ve been waiting for builds I’ve been playing with getting one of the most useful Firefox extensions working in Songbird. I’m talking about Greasemonkey. It turned out to not be as straight-forward as I was hoping so we made a few changes to the bird now it’s not so bad. Porting other Firefox extensions is probably pretty similar.

I pasted the patch but I’ll to my best to explain it in a way that might be helpful for people trying to port other extensions.

First, we’ve got to update install.rdf so that the extension knows it can be installed in Songbird. Basically that involves adding an em:targetApplication section. It looks like this:
<em:targetApplication>
<Description>
<em:id>songbird@songbirdnest.com</em:id>
<em:minVersion>0.3pre</em:minVersion>
<em:maxVersion>0.3</em:maxVersion>
</Description>
</em:targetApplication>
Most of this should be fairly self-explanatory.

Next we need to update chrome.manifest so that overlays that were targeted to Firefox’s main window (chrome://browser/content/browser.xul) are targeted to ours. Since our feathers can have different URIs we overlay an overlay that’s loaded by all Songbird windows that contain a browser:
overlay chrome://songbird/content/xul/mainScriptsOverlay.xul chrome://greasemonkey/content/browser.xul

Currently most parts of the default Songbird window uses similar structures and ids to Firefox. The rest of my patch is mostly cleanup.

So, go install greasemonkey - it’s compatible with our release candidates.

Caveat: Obviously (to me anyway) the perfect use for Greasemonkey in Songbird would be to inject Web API calls into pages that are Songbird-unaware. Unfortunately there are some incompatibilities between the way Greasemonkey executes scripts and the way the Web API does security. I’m working on some workarounds but for the time being you can’t access the songbird object from your userscripts.