Fixing $(document).ready() to work for any document

The first time I saw jQuery's $(document).ready(callback) idiom, I thought it was a great idea: not only is it readable as plain English, grep(1)able (it is available as $(callback) too, but I advise against using that in larger code bases, where you might need to dig up all references to it, at some time) and intuitive, it also lets you provide a different document object you are waiting for.

The first time I used it in the latter capacity I was a bit saddened to find that it was not quite that good yet; it always tests the same document that jQuery itself was loaded into. (At present time, meaning jQuery 1.3.2 and earlier.) The document object you pass isn't actually even fed to all the code that together implements the ready function.

As we needed it to do that at MashLogic though, my colleague Dave took to fixing it so it does indeed work that way, as per the jQuery ticket that has been sitting around for two years (from someone else that apparently wanted and expected the same thing), and I submitted a patch upstream. I'm hopeful it gets accepted for next jQuery release.

We even prepared a little test case that loads jQuery in an iframe and puts document ready callbacks on both itself and its parent window, which seems to work fine in all browsers and OSes we have tested it in so far.

I think the original ticket may have gotten closed over it often being a bit tricky to get a reference to the document object of an arbitrary frame or iframe for some frame you want to track -- the javascript security model forbidding DOM access to content in documents loaded from a different domain, for instance, and timing issues with grabbing a reference to the document object of a frame that is inlined in a document's source -- before we can get a handle to the document, it is a little difficult to have that parameter to pass to jQuery for listening in the first place, after all. But I hope such issues don't prevent the fix from landing, for the cases when we do have one.

Tracking multiple svn branches in git

I've been using git-svn for a while, to track projects still trapped in the subversion age, with git. It's not too messy to set up, though in order to get nice names addresses you need to map all the subversion identities to their corresponding name and email address. I recommend taking the time to suck out the entire repository history -- it's a one-time operation, and you get free offline history browsing and inspection.

If you have the names and email addresses of all svn committers, list them in a newline-separated file, each line reading svn-id = Person's Name <email@address> -- I kind of started tracking a list of jQuery committers, but got bored and/or side-tracked before finding the last ones. Anyway, if you go through the trouble, pass along this file on the command line (git svn clone -A committers.txt ...) when you create your local copy.

The docs for git-svn are not the best, and didn't mention how to import news into your local git repository for more than the branch you have checked out at the moment. The trick, which might be obvious for some but was not for me (thanks, singpolyma!), is to run git svn fetch --all to update your local repository with data for all branches, instead of (well, or besides) git svn rebase that just updates your currently checked-out branch.

And Bob's your uncle.

Updating Firefox extensions from 3.0 to 3.5

When I started writing this post, two weeks ago, 46% of the top 95% most used Firefox extensions on AMO (according to Firefox Add-on Compatibility Report) still did not manifest 3.5 support. The Mozilla team has been checking in with at least the topmost few of those projects (being one of the Greasemonkey maintainers, I got one of those pings, a few weeks ago), about whether we were having any issues upping the max-version of their extension to 3.5. We had not tried, at the time, but (happily) did not see any big issues, so we just let the release already out claim 3.5.* working.

For other extensions, like MashLogic which I hack on at work, that transition was not as trivial. Our integration surface towards Mozilla being larger than Greasemonkey's, more things changing underfoot get a shot at breaking things, and did.

The information about backwards incompatible changes available at MDC was and is still a bit sketchy, and did not cover issues we were hitting, at the time -- it seemed XUL documents were getting XPCNativeWrapper treatment in 3.5, that they did not have in 3.0, so we had to start adopting Greasemonkey-like roundabout practices to read and write properties of the XUL DOM. That's the kind of information that is good to be able to read about -- and there, specifically.

It's a wiki, though, so if you find something that isn't already there, while you are scratching your head about why things are not fine and dandy in 3.5 (due rather soon), please add your findings too. I did a brief writeup on my own findings.

For MashLogic, we actually ended up removing the xul page we had used for configuration to do the same thing in HTML instead; work we had already mostly done for our IE port, anyway. Other tidbits remain here and there, though, before we can claim having fully working functionality under 3.5.

On top of that, there is the not so enjoyable multi-week delay at AMO, getting our latest release through their review system. Our current release is thus so far only available if you look at their see all versions page, and grab the so-called "experimental" build on top. User reviews seem to help get the ball rolling a little, though, so if you try it out, we're really glad if you share your opinion with other users there by writing a review.

Whether you are a user or extension developer, sharing your experience like this really helps others. Especially if you do it where others go looking for it. MDC and AMO are rather good funnels for developer and user centric Firefox extension related things, and the more we use both, the better they get. Thanks for your help!