From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.9) Gecko/20020311 BuildID: 0.9.9 If user changes themes after composing an email message, subsequent compose windows come up with old theme. Steps to Reproduce: I will try to reproduce after filing this bug and restarting Mozilla. 1. Compose and send an email message (say, with Little Mozilla as theme) 2. Change themes (say, to modern) 3. Open new message compose window Actual Results: Message compose window displayed with previous (Little Mozilla) theme. Expected Results: Message compose window displayed with current theme in use (modern).

Reproduced. Composed message with modern theme, switched to classic, opened new message composition window - it displayed modern. Also adding this bug to tracking bug.

I presume you are using turbo mode? The current work arround would be to open a new compose window while keeping the one with the wrong theme open and them close first the good one and then the wrong one. Next time you will open a compose window, it will have the correct theme. I wrote specific code to clear the recycled compose window cache when switching theme but looks like this code doesn't work correctly anymore.

No, I would not touch turbo mode after my original brushes with it. Mozilla starts up fast enough without it, anyway. There is no problem working around. Restarting Mozilla clears the "discrepency," which is not really a bad problem. Actually, it's sort of cute. Maybe this bug could even be classified as trivial? Other than report bugs, I can only cheer the great job you are doing with Moz. Mail works great.

Do you want to close this one, now that a theme change requires a reload (A "forced" workaround!)? Or should it stay open pending the day that hot theme changes get reenabled?

I think we should keep it open for the future...

wontfix per bienvenu