« 2009-10-15 Trunk builds
2009-11-03 Trunk builds »

2009-10-23 Trunk builds

Fixes:

  • 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

This entry was posted on Friday, October 23rd, 2009 at 1:43 pm and is filed under Trunk. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.

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

  1. Manoj Mehta Says:
    October 29th, 2009 at 6:12 pm

    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?

    Thanks,
    Manoj

    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:
    October 29th, 2009 at 6:37 pm

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

    http://autonome.wordpress.com/2009/10/24/firefox-startup-performance-weekly-summary-7/

  3. Manoj Mehta Says:
    October 30th, 2009 at 11:07 am

    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.

    M

  4. dietrich Says:
    October 30th, 2009 at 12:21 pm

    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:
    October 30th, 2009 at 1:55 pm

    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:
    November 1st, 2009 at 10:29 am

    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:
    November 3rd, 2009 at 12:28 pm

    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?