I think this sort of thing is a bit dumb. It’s a poor substitute for writing posts that actually talk about oneself and one’s interests in a way that goes beyond the surface-gloss, pique-the-reader’s-interest level and actually say something meaningful about one’s interests or philosophy for life. The only one of these I’ve seen that I thought was close to reasonable was the console-history one that made the rounds sometime in the last year, because it was non-random information that said something about the person’s activities while not actually being all that shallow. It’s hard to think how one could talk about console history (which does say a lot about the commands the person runs regularly) in any more comprehensive and less glossy way, unless maybe you looked at the most common series of commands that had been run.

So here are the rules to this:

1. Link to your original tagger(s) and list these rules in your post.
2. Share seven facts about yourself in the post.
3. Tag seven people at the end of your post by leaving their names and the links to their blogs.
4. Let them know they’ve been tagged.

…and because I think this is partly a way to avoid saying something detailed and meaningful, I’m not going to share seven facts: I’m going to share seven facts that are not true. How’s that for non-useful information‽

1. I am an amateur body builder.
2. I am a poor speller.
3. I am the E4X sub-module owner. (Brendan said “close to”, not “are”, and besides: I hereby state, and mean all that I say, that I never have been and never will be the E4X sub-module owner; that if nominated by Brendan, I should peremptorily decline; and even if unanimously elected by every SpiderMonkey super-hacker I should decline to serve. Because I’m too smart to fall for that, and because I know what’s good for me. 😛 )
4. I don’t think there’s anything of interest in this recent YouTube video by Speaker of the House Nancy Pelosi, so you shouldn’t waste any time to watch it:

5. I thought I was wrong once, but I was mistaken.
6. I do not intend to do any more long-distance backpacking trips, or (logical or!) I do not intend to do any similarly long-distance cycling trips.
7. I didn’t spend a couple weeks in summer 2007 hacking Facebook in my spare time, or (logical or again, head spinning yet?) I didn’t give a class about Facebook’s JavaScript sandbox and how I could break it last January.
8. Bonus! My last name is de Morgan.

Now, let’s see about some victims from the set of people I haven’t yet noticed doing this:

• bz! one needs no reasons to select bz
• Jenny Liebig, a friend from pre/elementary/middle school and the last millennium (whoa) and intermittently since then due to divergent paths in life
• Jesse Ruderman, because he happens to be the closest person at hand to use at the moment
• Brendan, because he throws “salad days” and “epiphenomenal” around with impunity in normal conversation
• dmose, because he commented on a past post here
• Luis Villa, who knows more caselaw than I do (because he doesn’t just pretend to be a lawyer on TV)
• jminta, who doesn’t have a blog and will probably ignore this because lawyers are too often stuffy types (his present and/or future employers, that is)

UPDATE:

<jminta> Waldo: dump(“Things:\n”) for (var i = 1; i <= 7; i++) dump(“I can count to ” + i + “.\n”);

Earlier today I made one of the most, er, special commits to Mozilla code that I’ve ever made — entirely due to the commit message I used:

Bug 466905 - Fix JSOP_NEWARRAY to be not-buggy and use it when possible. NOT REVIEWED YET

If you read bug 466905 you’ll see in comment 20 that the patch was reviewed by Brendan and was committed with the requested changes. So why is “NOT REVIEWED YET” in there? It’s an artifact of how I manage patches-in-progress; I assign the description when I create the patch, and since I can’t know whose review will eventually grace the patch, I just add a note that I’ll see when I review the change just before commit, and I make sure to fix the description immediately before pushing it into the main repository. What happened here is that I forgot to review the commit message for proper reviewed-ness.

<firebot> Check-in: http://hg.mozilla.org/tracemonkey/rev/6475993319c4 - Jeff Walden - Bug 466905 - Fix JSOP_NEWARRAY to be not-buggy and use it when possible. NOT REVIEWED YET
<Waldo> aargh
<shaver> sounds like someone needs a pre-push local hook!
<Waldo> quite possibly!

There’s a clear flaw in this process: the bad-commit-message check (and remembering to do it!) is done manually and can easily be forgotten. So, at shaver‘s suggestion, I dove into the world of Mercurial hooks. After a little reading from chapter 10 and section 11.3, I present you with ensure-not-unreviewed:

To use, simply drop that somewhere on your system, chmod +x it, and copy the following lines into ~/.hgrc (.hg/hgrc if you want this configurable on a per-repository basis):

[hooks]
preoutgoing.ensure_not_unreviewed = /path/where/you/downloaded/ensure-not-unreviewed

That should take care of the problem of buggy descriptions permanently. Now if only I could write a preoutgoing hook to prevent pushing buggy patches…

If you’re adding assertions to Mozilla code, don’t use NS_ASSERTION, and do use NS_ABORT_IF_FALSE. That is all.

Every so often (okay, ALL THE TIME) someone (Linux users, of course 🙂 ) wonders why Mozilla doesn’t use platform libraries for things like networking code. One commonly-argued reason is that it gives us the flexibility to fix security problems without waiting on those upstream libraries to make the fix themselves — we control the code, and we can make the fixes ourselves.

Another reason not to use platform libraries occurred to me while reading Planet WebKit today, specifically the recent WebKit’s week – #7 post. Quoting from that post, added emphasis mine:

HttpOnly Cookie (38566)

An Internet Explorer extension (added in Firefox and Opera since) will soon be supported by WebKit based browsers. This restricts the access to certain cookies. They are only available for an HTTP request and so not from JavaScript. This is an important functionality to restrict the damages of an XSS vulnerability. This is not available in the nightlies because you need some updated Apple proprietary libraries (CFNetwork).

As noted, Firefox supports HTTPOnly cookies; after the patch to add this support was committed, you could download nightly builds which included the fix, and HTTPOnly would Just Work. No mess of upgrading platform libraries to make it happen, no separate-package updating, no waiting on Apple to update their platform libraries. (Incidentally, will Apple make those updates for 10.4 users as well, assuming they even decide to release a browser upgrade for a, er, “dying” OS release? Maybe, maybe not, who can say; “Apple does not comment on future products.”) Just download the build, build it from source yourself if you like building from source or if you’re a Gentoo ricer, and you have a working browser with the fix.

There are tradeoffs to be made rolling your own code when you could use something provided by the OS or by a third-party library. However, it should be equally clear that there are tradeoffs to be made going the other way, at least if you truly care about being cross-platform.

(On an almost entirely unrelated note, I was pleased to discover while writing this post that HTML5‘s outline-generation algorithm properly handles headings inside blockquote elements. Yay for specs anticipating my concerns! 😀 )

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.