Silverlight?

On my OS X box? How the fuck did that get there? I sure don’t remember installing it. Grrrr!

A little web searching later, and I found my answer. It’s silently installed with Flip4Mac (a set of Quicktime components to allow playing Microsoft proprietary media formats on OS X), which I had installed a week or two ago to try something, and then promptly forgot about. The installer doesn’t have a word to say about it, unless you click a little “Customize” button on the 5th screen on the install:

That really annoys me. Silent, sneaky software installs are evil, evil, evil.

At least Flip4Mac includes an uninstaller, so I ran that. It’s actually a package, so you’re confusingly prompted to “Select the disk where you want to install the uninstaller software.”, but it was otherwise painless. Now to just restart my browser, check about:plugins, and…

GAHHHH! It’s still there. Their uninstaller uninstalls the Flip4Mac bits, but not the Silverlight plug. Solution:

rm -rf /Library/Internet\ Plug-Ins/Silverlight.plugin/

It’s finally dead, Jim.

The old progress bar behavior had always seemed a bit odd to me — it would do nothing for a bit, move to about 15% point, and then suddenly finish. I didn’t get around to looking at why it did that until I used the updater on a Windows CE netbook. The device is a lot slower than a normal system, so the unusual progress bar movement could appear frozen for over a minute! That’s really poor UI feedback, so I set about fixing it.

You can read the gory details in bug 517102, but the end result is that the progress bar now tracks progress more accurately, and the updater runs 3 times faster too!

This was probably announced somewhere, but 3 other developers also didn’t know this was the case. So, I figured a blog post was in order.

Tinderboxpushlog already includes both sets of data, and I’ve just updated isTheTreeGreen.com to use both sets as well.

Result: Theory Busted.

Without disk compression, a full build took 23 minutes. With disk compression, 24 minutes. [Drive formatted between tests.] I’d guess some combination of not being IO bound plus disk seeks dominate, so compression doesn’t really help and just adds overhead. I also tried disabling “write-cache buffer flushing” to no effect, although I’m curious if splitting my build across two drives will help at all [src on one, objdir on the other; currently it's in a RAID-0 config].

One thing that would be nice is if parallel make worked correctly with Mozilla on Windows. If I build with anything higher than MOZ_MAKE_FLAGS=”-j1″, the build hangs at random (?) places. Seeing as this is a quad-core box (8-core, if you count HT), that makes me all sad and frowny.

Update: Mitch on IRC pointed out bsmedberg’s pymake work. With -j1 it’s about 30 seconds slower, but with -j10 it did a full build in 11 minutes (without hanging like a gmake build did!). Yay! I should also note that until now I’ve been doing Windows builds in a VM, which can take well over an hour to finish.

A couple weeks ago, someone on IRC pointed out that jorendorff had created a simplified set of instructions: https://developer.mozilla.org/En/Simple_build I think this is great!

There are still multiple steps (especially if you’re on Windows), but it’s a lot more streamlined than other documentation and is geared towards doing cut’n'paste. In a nutshell, it’s a lot less intimidating.

Back in November I implemented bug 463154, which added some additional data to the form history database. It now stores timestamps for when data was first added, when it was last used, and how many times it has been used. The first consumer of this data was the Clear Recent History dialog — we needed the timestamp to allow clearing the last hour (or whatever) of form history.

The first time you run a build with this change, all existing form history entries are assigned timestamps with the current time. So, if you were using Firefox trunk nightlies back in November 2008, you’ll have a bunch of entries with a first-used date set to around November 14th (the first nightly with this fix). Beta users got this in Firefox 3.1 Beta 2 (released December 8th), and it was also backported to Firefox 3.0.9 (released April 21st).

The second piece of background is that I recently fixed bug 243136, which adds support for expiring old form history entries. You might be surprised to learn that until this bugfix, we basically only removed form history entries when explicitly requested from the Clear Private Data dialog, or when a specific value was manually removed from the autocomplete dropdown by the user (hilight one and press delete or shift-delete!). Now, once a day or so, form history entries that haven’t been used for a long time will be deleted. The maximum age is determined by the browser.history_expire_days preference, which defaults to 180 days.

Now, if you’re clever, you might notice that November 14th 2008 + 180 days = today. If you’re not clever, well, reread the last sentence. So, Happy Form History Expiration Day! Note that expiration can only happen with Firefox 3.5 Beta 4 (or newer). And the exact date expiration starts depends on when you first ran a Firefox build that included timestamp support… Other common Form History Expiration Days may begin on June 6th (Dec. 8th + 180 days), and October 18th (Apr. 21st + 180 days). The latter will be extra special, since that’s the case that will apply to the bulk of our 1/4 billion Firefox users (most of whom will hopefully have upgraded to Firefox 3.5 by then).

Why do form history expiration at all? Three main reasons: privacy, relevance, and performance. Privacy and relevance are fairly obvious — retaining data forever isn’t good practice, and data unused for 6 months is highly unlikely to be relevant in the future. Performance is interesting… In my personal profile, I currently have 27,600 form history entries, with 12,700 of those from Google searches alone! Trudging through all that data takes time; in some cases an autocomplete dropdown can take hundreds of milliseconds to appear on my laptop. If I expire the data older than 180 days, those numbers drop dramatically — 4,600 entries / 1,800 from Google. This will immediately help improve form autocomplete performance, and help allow us to do more complex queries in the future (to improve the relevancy of the autocomplete results that we offer — stay tuned!).

Everybody say “awwwwww!”

I finally found a use for my N800 (which has been been sitting unused for some time). It’s now perched on my desk, under my monitor, giving me instant, up-to-the-minute status of the tree… Yep, that’s Fennec and http://isthetreegreen.com.

Sadly, the main observation from this is that the tree is almost never green these days. :-(