If you follow Mozilla stuff much, you probably do a lot of reading of bugs; if someone passes you a an unseen bug number, you’ll probably want to view that bug. (Of course, the Awesomebar’s suggestions make revisiting an old bug significantly easier than with Firefox 2 or with other browsers, so this trick’s much less applicable to already-seen bugs.) Here follows a few ways to do this, including one that I suspect very few people, if any, have ever used.

Method #1: You already know it

The simplest way is to type:

https://bugzilla.mozilla.org/show_bug.cgi?id=

…followed by the bug number. It’s a bit slow. Copy-pasting helps, but you have to re-seed the clipboard every time and possibly delete a bug number, if you’re pasting from a previous bug viewing.

Method #2: Use a bookmark keyword

Setting up a bookmark keyword can reduce the bug URL prefix to a few characters. First, load the following URL and bookmark it:

https://bugzilla.mozilla.org/show_bug.cgi?id=%s

Then open up Bookmarks < Organize Bookmarks…, find the new bookmark, and edit its properties. After selecting the More expansion triangle at the bottom of the window, type something like “b” in the Keyword textbox. From now on, typing b <bugnumber> in the location bar will open up that bug by loading the bookmark with %s replaced with whatever you typed as <bugnumber>. Repeat visits won’t require this as the bug will already be recognized by the Awesomebar (so hitting down a few times followed by Enter will bring up the bug again), but it’s still handy for first-time visits.

Method #3: keyword.URL

Is this as far as we can go? Can we reduce the typing any further in the new-visit case? I doubt many people have considered this, but the answer’s actually yes.

I assume most avid bug-followers already knew about bookmark keywords; after all, they date back at least to the Mozilla Suite. Keywords are a somewhat less-known functionality triggered by typing search text in the location bar and hitting Enter. Assuming you’re using something like the default setting, typing search terms in the location bar triggers a Google search using a URL specified as a hidden preference, and the search terms are tacked to the end of that URL.

What if we changed this URL to something other than Google? Particularly, what if we change it to recognize bug numbers and “fall through” on everything else? Here’s a URL which will do just that:

data:text/html,<title></title><script>onload=function(kwd){kwd=document.getElementById("text").textContent;location.replace((/^\d{1,6}$/.test(kwd)?"https://bugzilla.mozilla.org/show_bug.cgi?id=":"http://www.google.com/search?ie=UTF-8&oe=UTF-8&sourceid=navclient&gfns=1&q=")+kwd);};</script><span id="text" style="display:none">

You’d use this, of course, by typing about:config in the location bar, clicking through the nanny screen, typing keyword in the filter box, double-clicking the keyword.URL preference, and pasting the above URL in the dialog box.

I’ve been experimenting with this for a couple days, and it’s clear it isn’t quite optimal. There’s a noticeable pause between this URL loading and the redirect to the bug happening that the keyword.URL syntax makes unavoidable, it hardwires the fallback keyword URL, it offers only one Bugzilla (if you happen to follow multiple Bugzillas regularly), and it’s less elegant than the bookmark keyword solution. However, it does avoid a few characters, which might balance out the delayed load time; I don’t have the long-term experience (or ability to override significant bookmark keyword muscle memory, yet) to say for sure.

This last idea isn’t perfect, but perhaps people other might find it useful.