User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3a) Gecko/20021203 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3a) Gecko/20021203 I am using a CVS based build (all checkins until 12/03/2002 - 00:29) and I am seeing a weird bug. It only seems to happens in classic theme. I run mozilla, and I close all windows, in order to get a tray icon. After opening twice (and closing window once) mailnews with right click on tray icon, I cannot see anymore icons for folder and accounts in tree in the left pane. I noticed that my xul.mfl file grows up from 800 kb to 2,24 mb. Deleting it cures the problem. Reproducible: Always Steps to Reproduce: 1.Launch mozilla and close it in order to have tray icon 2.Open Mailnews and close it 3.Open again mailnews Actual Results: folders and accounts icons are gone in the left pane Expected Results: Seeing folders and accounts icon in the left pane. Icons are back when I delete xul.mfl I don't know if it is related to my building options : ac_add_options --disable-installer ac_add_options --disable-pedantic ac_add_options --disable-tests ac_add_options --disable-debug ac_add_options --enable-strip ac_add_options --enable-optimize="-O2" ac_add_options --enable-crypto Should I have to remove --enable-optimize="-O2" ?! Mailnews was working great before.

I don't know if this would help a lot, but, my last homemade and working build was based on checkins added until 12/02/2002 12:43.

Sorry to spam this bug :-(( After testing, classic and modern can show this annoying bug.

a XUL.mfl on 3-4 MB when using modern isn't unusual. It will grow whenever new chrome is cached. The size you mention, 2.24MB, sounds perfectly sane.

With my yesterday home made build, xul.mfl was only 800 kb, and so since a week ! And when bug is appearing, it grows up to 2 Mo, even more :-/ If I use modern theme, xul.mfl is only 1 Mb even less.

I compiled a mozilla without any options, and there are the debug message I get before I can see the bug. ASSERTION: not initialized:'mOriginalURLSpec != nsnull', file c:/mozilla/rdf/base/src/nsRDFXMLDataSource.cpp, line 862 ASSERTION: Main thread being held past XPCOM shutdown.:'cnt == 0', file c:/mozilla/xpcom/threads/nsThread.cpp, line 441 ASSERTION: not a UTF8 string:'Error', file ../../dist/include/string\nsString2.h, line 669 ASSERTION: length mismath:'converter.length() == dstLen', file c:/mozilla/xpcom./io/nsUnicharInputStream.cpp, line 272 I hope it will help.

Try with a blank new profile and bug is still alive :-|

*** Bug 183365 has been marked as a duplicate of this bug. ***

I meant to cc Brendan. Looking at the checkins, I see Boris landed a big CSS patch - Bug 107567, bug 47734, bug 57225, bug 178407. The 02 build is fine, so I don't see much else that could've caused this (sorry to point fingers).

OK. I see this problem in my debug build too... investigating.

bienvenu was seeing plenty of xul.mfl problems recently, so cc him.

This is mind. The problem is that folderPane.css is not UTF8 but we try to load it as such. More to the point, when fastloading CSS is loaded via LoadAgentSheet from AddPrototypeSheets() from nsXULDocument::ResumeWalk. This is _wrong_ for so many reasons... (like non-chrome sheets used in chrome that would fail for fastloaded chrome?). Anyway, when not fastloading, we use LoadStyleLink instead. This uses nsConverterInputStream, which handles conversion errors "gracefully" (read: does not drop the data chunk entirely). LoadAgentSheet, with my patch, uses the UTF8ConverterStream, which drops data on conversion errors... The fix is to not use UTF8ConverterStream.

s/mind/mine/

Is that like eating the other white meat?

Oh, in my build I've moved the &rv to the previous line; no real reason to carry it over there.

Comment on attachment 108157 [details] [diff] [review] use the other converter stream sr=sspitzer, but please get module owner review. (or are you the module owner?)

Comment on attachment 108157 [details] [diff] [review] use the other converter stream 8092 is a magic number ;-) and bz's going to update the comment to indicate that the utf8 assumption is bogus :-(

Comment on attachment 108157 [details] [diff] [review] use the other converter stream bz is definitely one of the owners of this code (and I'm not). The patch looks fine to me, though, for whatever that's worth.

fix checked in.

I open / close mailnews windows 6 times, and no problem. Thanks for fixing this nasty bug :-)

*** Bug 183654 has been marked as a duplicate of this bug. ***

Hmmm, I think I like the mail folder list without any icons... ;) Would it be too much trouble to make it configurable?

Yes, if you ask for it in this bug. File an rfe on the mailwindow front end instead...

Verified FIXED on: Mac OS X 10.2.2 - 2002-12-05-08 Windows 2000/XP - 2002-12-05-08 RedHat Linux 8.0 - 2002-12-05-08 Checked both Modern and Classic.