2009-10-23 Trunk builds


  • Fixed: 448602 - Have a way to enumerate event listeners.
  • Fixed: 482402 - Enable "svg.smil.enabled" pref by default.
  • Fixed: 517902 - Reimplement image properties, using the existing "Media" panel.
  • Fixed: 522416 - Tab Previews must not do sync http requests.
  • Fixed: 327323 - Can't "Open with" files that are send as application/octet-stream (or other "unknown to firefox" mime types).

Fixes for recent regressions:

  • Fixed: 516665 - Distorted images with moz-icon://*?size=dialog.

mozilla-central pushlog for 2009-10-15 04:00 to 2009-10-23 04:00

Windows builds: Windows nightly (discussion)

Mac builds: Mac nightly

Linux builds: Linux nightly

7 Responses to “2009-10-23 Trunk builds”

  1. Manoj Mehta Says:

    Is it just me or are others beginning to notice how slow the latest Namoroka nightly build is on a cold start as compared to IE8, Google Chrome and Safari on Windows? Is there something going on in trunk to fix this perceived (or real) slowness?


    User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2b2pre) Gecko/20091027 Namoroka/3.6b2pre (.NET CLR 3.5.30729)

  2. Jesse Ruderman Says:

    There’s a whole team, of sorts, working on Firefox startup performance. You can read about their progress in dietrich’s weekly summaries:


  3. Manoj Mehta Says:

    Thanks for the update Jesse. I was poking around and couldn’t find a prefetch or super-prefetch file for Firefox on my Vista machine (maybe I didn’t look hard enough). Cold start performance of Firefox would be improved substantially if Windows could figure out the order of page loads for Firefox.exe; the reason why applications *feel* snappier on Windows 7 is because of super-fetch and dll load dependency removal.


  4. dietrich Says:

    Manoj: Thanks, I noticed that there aren’t pf files for Firefox on my Win7 beta either. For some reason Superfetch doesn’t seem to be caching it, even though it’s constantly in use. I’ll poke around and see if there are things that can prevent apps from being monitored and cached by Superfetch.

  5. dietrich Says:

    Manoj: The superfetch file for Firefox is currently in /windows/prefetch, but I didn’t do anything to change it. Perhaps you (and I) have things like antivirus programs which push other apps out of the cache? (There’s a ceiling on how many apps are cached)

  6. Zak Says:

    For those of you that don’t want to wait for the startup time to improve, you could just use Firefox Preloader. Obviously adds some time to your boot, but it does work quite well. It just keeps firefox.exe in memory. I’d say it’s fairly close to Chrome if you use it (still not as fast, though). Works with 3.5, 3.6, and 3.7 from what I’ve tested.

  7. Manoj Mehta Says:

    Dietrich: I didn’t know there was an upper bound on the number of .pf files stored by Windows, but you might be right about an upper bound (otherwise the disk would get clogged with .pf files). From my memory, I think they use a LRU algorithm to purge files from the pf cache; this still doesn’t explain why Firefox wasn’t in my pf cache – I tested with just firefox open on my desktop after a fresh reboot.

    Regardless, is there a way for us to figure out how Chrome loads in a jiffy and employ some of their techniques in Firefox?