This was originally written early September. The patch was live late September. And 4 weeks of results later, this post. My apologies if I mixed past and present tense

The number of add-on downloads was always an interesting figure to me. Over several months, one of my add-ons was getting over 100 downloads a week without any promotion. But my ADU remains almost constant every week. It may increase by a few, but compared to the number of downloads, it only seemed like I got an abnormally low number of conversions. Less than 15% of users who downloaded my add-on turned into a ADU.

This didn’t seem right, so for 0.7 release of Safe extension, I added some code that sent me some info whenever someone uninstalled from the Add-ons Manager.

According to the add-ons dashboard, I had 78 ADU users for version 0.7 (submitted 2009-08-14. Averaged over a period of 1 week.).

How many downloads since it was uploaded? About 659 (I likely uploaded it late evening, so it might be less then that). So about 11% of the users that downloaded the extension didn’t uninstall it. But how many users chose to uninstall it using the Add-ons manager?

Ten.

So what of the other 500+ users? How did they uninstall my extension? I wondered whether web crawlers were downloading my extension. 500 seems like an awfully big number. Maybe a broken crawler? Well, actually, it turned out that AMO’s robot.txt did not exclude robots from downloading extensions at all. And how often a crawler visits is determined by the provider. Google cache takes a snapshot around once every week for me.

I realized that these numbers won’t be accurate because there are more ways to uninstall an add-on, including new profile or deleting the add-ons folder from the profile. But these seem like rare cases. Certainly not responsible for such a misleading number.

I filed and fixed a earlier bug to have robots.txt exclude crawlers from the /downloads/ path of each of our localized versions of AMO.

After 4 weeks, my stats have leveled off and the number of downloads have dropped by about 10 a day. My add-on downloads dropped from >10 to about 3 a day. This won’t be considerable to popular add-ons (AdBlock Plus shows no difference, they are still getting 80,000 downloads a day). Looking at the statistics on AMO, total downloads have dropped over 100,000 a day since the stuff went live last month. Good stuff.

A few weeks ago, I wanted to do some C++ Mozilla coding to make sure I wasn’t going soft. But I didn’t really know what to do. I left it for a bit until I found something weird about the HTML5 spec – there was a method of testing whether metadata has been loaded, but no way to expose the metadata (eg. song title, artist, album, etc) to the user such as through page info.

I think this will be useful. As media starts being embedded into the web browser, it would make sense to start exposing this to the user. I know there have been a few instances where I was listening to something on the radio, but there was little hint of what the song was called (I usually tried to remember a few lyrics and did a Google search. Mixed success).

I brought this up in the whatwg irc channel, and apparently this is being considered for the next version of the spec. Which is understandable, because the server can always display the metadata. But often, media may not be central to the website. For example, background music.

I started look at the Audio/Video backend stuff that moz uses. It got confusing real quick (it doesn’t help that the audio code itself is completely empty). Plus I was in a hurry. So I decided to implement it as an extension.

It was a lovely experience. I had a few problems, including finding out that audio/video wasn’t actually being saved to the cache (bug 469446). It was checked-in like 2 days after I found it out. Also, I hate string very much. The string guide helped, but it is still awful. And I made firefox crash a few times because I’m a nsCOMPtr n00b.

Right now, this extension is working only with ogg vorbis files. Which is stupid because <audio /> is rarely used anywhere, and if it is used, only with certain conditions (wikimedia commons uses the audio tag, but not really. Apparently, the video/audio tags start automatically downloading the media even if it isn’t under autoplay. This is a mess if you have dozens of audio tags in one page. bug 464272). It is so rarely used, that I had to create a audio demo page for testing purposes.

Using it is very simple. Right-clicking on a audio tag brings up the context menu. I decided to use the context menu over Page Info because the media tab of the Page info dialog is very much geared towards images, and that code has to be changed in the firefox source (it’s not easy/pretty to overlay).

Which brings up the audio’s metadata

While a lot of metadata is displayed, some isn’t. For example, iTunes has support for cover art as a COVERART header. While you can put that in vorbis, it should be noted that it isn’t widely supported. So I decided to put in only the standard headers for now.

This is dealing with C++ code. Which is much more dangerous than javascript code because NS_ERROR_OMGWTF doesn’t appear in your error console when I try to free an uninitialized pointer. I made basic checks so hopefully nothing bad will happen. But I didn’t do extensive checking in case we have a bad ogg file or something.

Well, to be fair to me, I always save the function’s return value. I just didn’t check whether it passed nor did anything about it. And this won’t just crash at any time. It’ll crash if you try to load the metadata (I’m very nice like that).

The name of the extension is saraswati, named after the hindu God of music and knowledge (really, a Google search helped out a lot here). Please enjoy! (Linux x86, x86-64 and Windows x86 only right now)

What I thought was a bug in the jQuery.browser, turns out to be a bug, but on a function that was deprecated (according to their nightly source) and therefore not likely to be fixed. The bug occurred when calling jQuery.browser.safari in Google Chrome. It would return true instead of false because the user agent had the word webkit in it (yes. That’s the browser sniffing method they use). Some simple methods work better than others.

I need browser detection so I can point users to helpful places when they have javascript disabled. Turns out my site is really broken when js is disabled. And when css is disabled as well, but that’s another problem. I made a quick and dirty jQuery plugin that includes konqueror, Google Chrome, and fixes the bug mentioned above.

Using it is as simple as :
$.browser.konqueror
$.browser.chrome

But don’t take my word for it. Try out the demo and view the source! It’s under the MIT license. It’s not included in the source because it is just too much overhead.