This morning someone new dropped into #fx-team on IRC, asking about a reproducible problem and how to submit a patch. Normally #fx-team is a fairly busy channel, but since we were all at the Mozilla All-Hands last week, people were traveling and recovering… So it was 12 hours of dead silence before anyone replied. Not great, but also pretty rare. :-(

Anyway, the awesome part was that in that time this person managed to grab the source code, diagnose the problem with gdb, fix the problem, and then blog about it — check it out. That’s pretty awesome! (Oops, I already said awesome once. Still deserving of a 2nd ‘awesome’. :-)

The timing couldn’t have been better. At the All Hands, I went to one of the talks by Ubuntu’s Jono Bacon on Growing and Maintaining Community. It was pretty awesome (3rd time, yes I know). Obviously Ubuntu has a large community, but I was hadn’t realized just how much thoughtful effort has gone into improving it… TONS of fantastic ideas and practices that I hope Mozilla can also make use of. The one downside, though, was that I came away feeling a little bummed at how much work need to do to reach the high level of wide-ranging, effective engagement Bacon et al have developed. So it was really splendid timing to have a new community member pop out and have a good experience.

Today was a good day.

Now that’s out of the way, let me refer you to this post by Notch, creator of the wildly-successful indy game Minecraft.

Someone tweeted me about a joking campaign to add 3d modeled snouts to the pigs in Minecraft, so I did.

I think this is one of my favorite parts of working on Firefox. “Hey, let’s fix that” … “*bam* Fixed”. That’s not to say every community suggestion or known bug is simple to fix, but when it is it’s super satisfying.

*drumroll*

TOP SEVEN THINGS ABOUT JUSTIN DOLSKE!

7. Has a cat!

Hmm. Kinda off to a bland start, but then I never found Letterman to be very funny.

Anyway, yes. I haz a cat. I saw her hanging around as a stray, and began to leave some cat food outside for her. Then, after a couple rainy nights of her stopping by to eat (as well as look sad and lonely), I opened up my door to put out new food… She ran inside (!) and I realized I had just been adopted. :-3 She’s a fairly small cat (and was starved when she found me), so I named her “Munchkin”. We’re snuggle buddies, and she’s so sweet and well-behaved it’s ridiculous. _Ridiculous._

I have pictures from when I first got her, as well as some more recent shots. Oh, and she’s Kind Of A Big Deal, as the header on the URL-shortening side icanhas.com.

6. Built a Firefox logo from LEGO!

I’ve previously blogged about this. It’s awesome enough to mention again, I’m quite pleased with how it turned out.

5. Is a hueg space history nerd!

I’m keenly interested in NASA’s (and other countries’) space programs, both past and present. I first got hooked after reading an article in the newspaper on the 25th anniversary of the Apollo Program, when I read that we had landed (men) on the moon not just once, but actually 6 times. I was stunned that that I had never learned that before, and was determined to know more.

I particularly enjoy the nitty-gritty, engineering details of programs. It can be hard to find — mass market books don’t want to get too technical, and NASA’s own outreach is mainly for school kids — but there are gems like this book, and NASA’s Apollo Surface Journal, or Apollo Flight Journal. NASA now has lots of very high-res photos from recent Shuttle and ISS missions, which you’ll see as wallpapers on my desktop at work. They’re fun to zoom into and examine for little details.

4. Can do software _and_ hardware!

I do software for a living, but I also love to dabble with simple electronics on the side. I can fairly claim geek points for knowing how to solder (fine-pitch SMT, at that!), doing design and etching of my own boards, reading datasheets for fun, and hoarding components that will be “useful someday”. All self-taught, but also not very good at it. :-( They say software guys shouldn’t do hardware, and vice-versa — it’s probably true. But it pleases me, and I think it’s more about the journey than the destination.

My first serious interest came after reading about a neat “forever flasher” project on alt.hackers, back in the day… It was just a little LED blinking circuit (solar powered, with supercap for storage), but the clever part was that it was hooked up with fine magnet wire and permanently cast in the center of a clear acrylic block. From there I graduated to building a beer-keg monitoring system with a DalSemi TINI kit. My hardware was flaky, but it did have a web interface. And I get bonus points for writing a GIF encoder in Java, mostly from scratch.These days I’ve been tinkering with an Arduino board I got from SparkFun’s first Free Day promo, as well as TI’s nice little MSP430 LaunchPad kit (just $4.30!).

3. Loves Beer!

Did I just mention beer? I think I did. Yes, I’m a bit of a beer snob… Ok, ok, I’m a big beer snob and huge hop-head. I’m in heaven with the amazing beer variety available on the west coast. If someone could please move Belgium over here too, I’d appreciate it.

Instead of a long monologue on how much I enjoy all things brewed, I’ll just plug BeerAdvocate here. Subscribe, it’s just $15 cheap!

2. He’s an international fugitive from the CIA and NSA!

I miiiight be stretching the truth here slightly. :-) But back in 1997, I helped out with the DESCHALL Project, a massive, distributed effort to brute-force a message encrypted with DES. (Purely white-hat, it was a contest sponsored by RSA Security.) After 3 months and tens of thousands of participating systems, a 200Mhz Pentium-90 owned by some guy in Utah stumbled across the correct key, and we won. (The secret message was “Strong cryptography makes the world a safer place.”)

This was the first known successful brute-force attack against DES. We got some press (page A3 of the Wall Street Journal!), I later cowrote a USENIX article, and overall it felt good to play a tiny role in the crypto wars of the 1990s… Back when the government considered cryptography to be munition and still tried to tightly control its export. Coincidentally, we won just days before the US Government gave Netscape permission to export 128-bit crypto (instead of the ridiculously limited 40-bit limitation it required before).

I didn’t write any of the crypto code for DESCHALL, but I did help with organizing the project, wrote a proxy to tunnel its UDP client/server control traffic over TCP, made a graph server for people to track their progress, and (most fun of all) made an export-control download page that did a reverse-IP lookup of the user, then a WHOIS lookup on that domain, and finally scraped out an address to see if they were likely in the US. Oh, and I ran the DESCHALL client on about 200 systems at Ohio State University… Over the 3 months, they tested an 100 trillion DES keys — or about 0.1% of the problem space. One year later, the EFF built Deep Crack, which could crack a DES key in just a couple of days.

Eventually I should file a FOIA request to see what the US Government knew about the project and us. :-)

1. Starting his 6th year at Mozilla!

Last but not least.

My first day working for Mozilla was August 7th, 2006. 5 full years ago, nearly to the day. Wow. Looking back, I am concurrently full of things to say and speechless. I’ll just say it’s been an amazing experience that never gets old — every day, when the office elevator doors slide open and I see “Mozilla” on the wall, I feel awed and humbled.

I can’t wait for what the next 5 years will bring!

And that’s tonight’s Top 7 list!

*throws card through fake window*

Good night, ladies and gentlemen!

One could instrument the code and get nanosecond-level precision — but it’s difficult to know where to insert probes, and you still may not be measuring what the user is actually seeing. A more direct “ground truth” would be to use a camera to record what’s displayed on the screen, and then examine the resulting video frame-by-frame to obtain data… I dabbled with this briefly last year when working on a Windows CE bug about slow-opening windows and menus. But more recently, Alex Faaborg has started a investigation of the Firefox UI using a significantly refined technique.

A problem Alex quickly ran into, though, is that it’s hard to look at a video and know exactly when the user clicked a mouse button. If only there was some visual indication of the mouse button state… Hmm! That was enough to start the wheels turning in my head, yadda yadda, and one weekend later I had complete a nice little hack that added some LEDs to a mouse so you could see the button states.

Some pictures… (See Flickr for the whole set.)

First, you’ve got to drill a nice hole (*)… I cringe every time I see someone mention doing some hack with a Dremel, because most of the time the result looks like something a drunk monkey with a chainsaw would produce.

Next, tap into the mouse’s microswitches (which are tied to ground) and the USB’s +5V.

Finally, route things nicely. Behold, the four-as… err, two-wired mouse!

This is the business end of the extra wire now attached to the mouse. 2 LEDs (and a couple of resistors) wrapped up in some heat-shrink tubing. When a mouse button is clicked, one of them lights up — red for right, (ye)llow for left.

This is a pretty simple little hack, but it was especially fun it’s not often us software guys get to do hardware stuff. And, hey, it even worked on the first try!

Sadly, there is one little problem… While the hacked mouse worked flawlessly for me, it immediately failed to work for Alex — the OS didn’t see mouse clicks, even though the LEDs lit up. Oh no! Luckily I had made the LED tail detachable (not shown here), as it turns out that if the mouse is plugged into the computer with the LED tail attached, it doesn’t work. But if it’s plugged in without the LED tail, and then the tail is plugged in afterwards, it works fine. I’m guessing that I just need to add some decoupling capacitor where I tapped into the switches, as the mouse’s IC was ok with the short traces to the switches but not the new 4-foot wires hanging off it. Or maybe a pull-up resistor? Both? Dunno exactly what the problem is yet — this is why I’m a software guy. ;-) What say you?

• 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.

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 libnss3.so 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.

(cut strips at bottom so people can have their own tear-off miniblizz!)

• 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.

(reference)

;-)

So I next loaded it up in Safari, to see how it compared. Previous versions of Firefox have had some jerky-video problems (due to running garbage collection at bad times or doing too much main-thread disk IO for session restore), so I was fully prepared to file a bug on the problem — smooth playback in another browser would be a strong indication that something in our code was causing the poor performance.

However, what I found was that playback in Safari was much much worse that on the trunk Firefox build I was using. While Firefox yielded good playback with an occasional glitch, Safari gave a consistently poor playback of around 3 fps.

There’s one clear, inescapable conclusion here: Flash sucks. :-) But seriously, folks, I’m happy to see that trunk builds perform well. I should still file a bug to investigate if we’re responsible for the occasional stutter in playback (or if that’s just Flash), and if results on Windows are similar to OS X or not. But I’m still pleased to see that this arbitrary trunk nightly — not even beta quality — is doing a good job.