You are currently viewing a snapshot of www.mozilla.org taken on April 21, 2008. Most of this content is highly out of date (some pages haven't been updated since the project began in 1998) and exists for historical purposes only. If there are any pages on this archive site that you think should be added back to www.mozilla.org, please file a bug.

Skip to main content

cached compose window FAQ
Seth Spitzer (sspitzer@mozilla.org)

What is the "cached" compose window?
Instead of destroying the mail compose window on send (or close) just to create a new one the next time, Mozilla Mail will "cache" the compose window on send (or close), and use that instead.  The downsides are that we have had some bugs, it complicates and bloats the code, and it requires more testing.  The upside is that is has been a major performance win

Why did you do this?
Back 0.9.7, we hit a wall with the compose window.  Any new window performance problems that mozilla has are especially painful in mail compose, as we need to create a new compose window on every new mail message or reply.

But we noticed that the common usage pattern is to compose, send, compose, send, compose send.  We decided it would be worth the trouble to cache the compose window.  If  the user has this usage pattern, we wouldn't have to create a new window.  We could just hide it on send, and then show it on the next compose.  If the user opens (but never sends or closes compose windows), this trick will not apply to them.  But this is not a common usage model.

How do I test it?
On window and mac, the cached compose window is on by default.  To test it
  1. start mozilla 
  2. do new message.  this is a new compose window.  notice how long it took.
  3. close or send the window. (the compose window is now cached)
  4. do new message again.  this is the cached compose window.  it should have been faster than in step 2.
  5. close or send the window. (the compose window is cached again)
  6. do new message again.  this is the cached compose window.  it should be as fast as in step 4.
  7. do new message again.  there is no "cached" window, so this will be as slow as step 4.
  8. close one of the compose windows.  (this window is now cached).
  9. close the other compose window.  (this window is not cached, since you already have a cached compose window.)
  10. do new message again.  this is the cached compose window.  it should be as fast as in step 4.
  11. do new message again.  there is no "cached" window, so this will be as slow as step 4.
We cache at most <n> html compose windws and <n> plain text windows, where n is the value of the hidden pref.

What's the hidden pref to control it?
user_pref("mail.compose.max_recycled_windows", 1);
We default to 1 on mac and windows, 0 on unix. This feature is not on by default for unix users.  (see below)

Why is it not enabled on unix yet?
See http://bugzilla.mozilla.org/show_bug.cgi?id=130581 (kde problem)
See http://bugzilla.mozilla.org/show_bug.cgi?id=137698 (the bug to enable on linux)

Where can I read more about it?
See http://bugzilla.mozilla.org/show_bug.cgi?id=104989