Status update

One of these things I did not actually work on:

  • JavaScript / js-ctypes implementation of WeaveCrypto
  • Migration and replacement of localstore.rdf with a .json backing store
  • Rickrolling Fligtar’s new dashboard
  • Tab-modal dialogs proof-of-concept
  • Fix multiple master-password dialogs with session restore
  • Ported Firefox to ColecoVision.

Weave, crypto, and JavaScript

tl;dr: fa20ae35b8ac53b28dde4fc333aba21f 🙂

Up until now, Mozilla’s Weave add-on has been living with an awkward implementation detail: a binary component. When I wrote Weave’s current cryptographic component back in 2008, in order to use the crypto code that’s already in Mozilla (ie, NSS) there was no choice but to write C++ code. NSS doesn’t export any scriptable interfaces at all, and its partner-in-crime (PSM) exposes only a limited set of high-level functions — none of which was useful for Weave.

The C++ code has been working fine, but has a number of serious drawbacks… A binary component has to be compiled for each supported platform (originally just Windows, Linux, Mac x86 and Mac PowerPC). That results in a bigger download, and makes it a pain to support new platforms (like 64-bit Windows, 64-bit Linux, 64-bit Mac, Maemo, Windows CE/Mobile, Android, etc). It’s also a barrier to new developers — compiling a binary component requires a build environment and XULRunner SDK, whereas hacking on most extensions requires nothing more than a text editor. Luckily the C++ code has been quite stable, so Weave was able to hack around this by including pre-compiled binaries in the Mercurial repository.

But enough is enough.

The next (trunk) version of Firefox includes JS-CTypes, a feature that allows JavaScript to interface with native code. Think of it as dlopen/dlsym for JS. By porting the WeaveCrypto component over to JavaScript + JS-CTypes, Weave is now able to talk with NSS directly, without any C++ code. It basically Just Works — adding support for Mossop’s Palm Pre port of Firefox was literally a 1-line change. Adding support for Android was a 4-line change (only because they’re tricky and put in a sub-directory).

I should also mention that unit tests were a HUGE help in getting the new code completed. I wrote extensive tests for the C++ version of WeaveCrypto, and once the JS-CTypes version was working with those tests I was able to make a full-up Weave sync work with the new code on the first try. Easy-peasy!

If you’re interested in seeing what this new code does, take a look at the bug and the code in the Mercurial repository. Note that the XPCOM interfaces are fairly specific to what Weave wants to do — it’s not a general-purpose JS crypto API. But it’s a huge step towards making it easier to do crypto code in JS extensions — and perhaps in the future we’ll look at making a real general-purpose crypto API for extensions; it’s certainly an interesting problem! If folks are interested in helping out with such a project, let me know.

Status and stuff

A bit of stuff I’ve been up to lately:

  • CSS Transitions for videocontrols. Finally got around to landing this. There’s really no visible change, but it replaces and simplifies a whole bunch of Javascript-driven animation code. CSS Transitions are really nice to work with.
  • Use Services.jsm in Login Manager. Gavin added Services.jsm to trunk not that long ago, and it’s one of those things that’s so slick to use we should have done it years ago. There’s been a small flurry of patches to convert various code over to using Services.jsm; it’s trivial work but is really good for code hygiene.
  • A 3rd round of crashed-plugin UI tweaks. Hopefully we’ve got it nailed this time! Also fixed the last of the significant crashed-plugin UI bugs, and started a cleanup of the trunk code in preparation for future work.
  • Reviews of 2 Form History patches for “good first bug” bugs — I need to start tagging more of these! With these fixes, we now avoid saving credit card numbers, and there’s a new option (off by default) to suppress saving data on SSL pages. I’ve also been finishing up patches for helping Weave to sync form data.
  • Finished reviews, tests, and landing for automatic proxy authentication. BenB’s patch is now in the tree, though it’s currently preffed off. If you use a proxy with authentication, enable “signon.autologin.proxy” and give it spin.
  • Finished porting of the C++ WeaveCrypto module to JS-CTypes, and was able to successfully sync between profiles using it.
  • Thunzilla!

Coming up soon:

  • Finish up last quarter’s E10S scoping, and get this quarter’s E10S goal underway.
  • Final polish on the JS-CTypes WeaveCrypto, get it out for review.
  • Doing a little 1 or 2 day sprint with zpao to port most of the remaining C++ form history code to Javascript.
  • Death to (almost) all superfluous Master Password prompts.
  • Other random awesomeness.


Last week I noticed something quietly frustrating about reading bugmail in Thunderbird… Someone had generated a bunch of bugspam while shuffling around bugs into new components, and I was cleaning it up. For the most part, sorting the messages by time and deleting a range took care of things. But, I realized, you can’t actually see who generated the bugmail from looking at the folder summary. So if someone else happened to make a change within the spam-timespan, I couldn’t easily tell. Sigh.

All bugmail comes with a From header set to “” (which is basically useless), but there are also a number of other X-Bugzilla-* headers in each message. X-Bugzilla-Who, specifically, has the data I wanted to see. I just needed to have it exposed in Thunderbird!

I filed bug 557945, and the mail folks pointed out this could easily be done with an extension, and even provided links!

So, yadda yadda, a short time later I had written Thunzilla:

Thunzilla is available on AMO. Enjoy!