I am in the process of creating a new Firefox add-on that will hopefully change a bit how we navigate some sites. Until now, keyboard navigation for the vast majority of sites has been simply unusable. Even though websites have a layout that can easily use a keyboard, it often relies on either remembering shortcuts or tabbing through. You are almost exclusively limited to a mouse when using a full-featured browser such as Firefox, Chrome, and IE.

Personally, I hate using the trackpad on my laptop. After extended use, the heat and the friction take a toll on my fingers. I have an external USB mouse, but that often becomes a bother as the laptop is moved around from one location to another. Yes, wireless mice, but again we’re not really fixing the problem.

For simple navigation, it’s almost a crime that I cannot tab between links and major components of a web site’s navigation.

The tabindex HTML attribute has gone largely unused when browsing the web. Perhaps for a myriad of reasons – it’s hard to re-order manually, and for many web developers it’s not worth the time or effort.

Even for everyday use, it becomes ridiculous how crappy it the tab key can be. Think about this:

• For a Google search result, the tab key must be hit 12 times before it focuses on your search text. Another 3 tab strikes before it takes you to the first result. Another 5 times or more to get to the second result – not counting Google’s quick links.
• For planet.mozilla.org, each tab key will go through every anchor link in each person’s blog post. Oh, and it takes 6 tab keystrokes to go to the first article.
• For reddit, it can be a little better. If you just use tab, you’ll go through each “share” link first. Which is stupid. If you activate “jump to content” it will go through image->link->domain->usersubreddit->comments. Which is still a lot for one result.

This is how I would order the tab key on a Google search result:

Possible tab order on google

I would probably use the top Google bar the least when doing a google search. Each time you hit tab, it will cycle through the search box, 1st result, 2nd result, etc. until you hit n-th result.

This would be great in an ideal world. A Firefox extension could do this, but for my purposes my extension does not do this. It doesn’t map the tab key. It instead uses the key right above it. Like tab, CTRL+` will cycle forward and SHIFT+~ will cycle backwards.

I call it tabcomplete. It’s not as pretty as tabcandy. I think a large part of my user-base wouldn’t be most users. Users seem content on using the mouse, and that’s fine. But for a guy who works in vim, this is a nice to have extension.

Today I submitted version 0.7 of the safe add-on. This was not a version with additional features, but rather a version that collects stats from users who uninstall the add-on.

I mainly did this because I wanted to know more about why only a small percentage of users who downloaded my extension continued on using it. How long have they used the extension? What options have they enabled (if any)? Where are my users coming from? I stopped short of asking people to complete a feedback form, instead opting to just send data to my server. It’s relatively anonymous, except for the IP address which gets recorded.

Unfortunately, this doesn’t really give me useful statistics from people who stay with my add-on. Which is still useful. My best hope is that it’ll answer at least one of my questions that it was set out to answer.

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)

As the addon review queue grows beyond 600 nominated and updated addons, it is more important than ever to make sure your extension passes review the first time around. Editors have a review guide, and a well hidden but publicly viewable set of policies. But here is a quick list of the most cited reasons for addon refusal :

1. Addon should have at least 3 user reviews before being nominated. External reviews count too, but you have to mention them in your nomination message. Softpedia reviews do not count.
2. Wrap your loose variables. All objects, variables, and anything that your addon makes global should be wrapped to avoid conflicts with other addons.
3. Look at the error console. Is your extension throwing up javascript errors? Fix it. There are some options you can set in about:config to help you with this.
4. You break functionality in the host application (Firefox, Thunderbird, etc.).
5. Your extension doesn’t work properly, or showing unexpected results. This is what user reviews are expected to catch, but you really should get someone who wasn’t involved to test and report bugs.

There are other less common things that can get you busted too. I’ll just list them here for completeness sake :

5. Including remote javascript/css or other files, anywhere. Include them in your xpi file instead.
6. CSS warnings on the error console if your submitting a theme.

If you have any doubts, check the public policies page linked above.

And don’t ask when your extension will be reviewed in the comments. Because every answer will be the same : When someone gets around to it. It could be sooner if you’d help!

One internet phenomena that seems to be popular at Mozilla (at least, for some people) is rediculously cute animals and broken english in both in spelling and grammar known as lolspeak. So much so that Paul O’Shannessy (zpao if the name doesn’t ring a bell) created the bookmarklet that takes flickr images and turns them into canvas drawing overlaying text to it (called LOLify). The bookmarklet was based off of flolcatr, which brings more lols (well, some of the time anyways. The true lols come of the pics of middle-aged women).

Using that as inspiration, I worked on turning into a Firefox extension. Particularly because I wanted more flexibility out of it. For example, right now the bookmarklet takes random stuff out of the flickr comment and puts them into the image. But I wanted to add in my own stuff to either the top, middle, or bottom of the image and be able to align it left, centre, or right.

After spending all night doing it (I was afraid I would lose interest or get lazy if it took more than one day to complete), I uploaded what I had to addons.mozilla.org. After a good nap, I went back and fixed some pretty ugly errors and uploaded a much better version. I ended up with the name of kyoote (cutie), because it’s one of the words used to describe a fennec. And fennecs are extremely unrepresented as cute animals, even though they are adorable. And from today forward, let friday also be known as fen[nec]day.

Original image taken from deadstardro

So sit back this fenday and enjoy a meowtini

Update: Clarification based on comment