Build ID: 2001-10-19-09, Windows 2000. Summary: Selection in the folder pane fails to load folder's contents. I suspect Fastload, but can't prove it. Deleting xul.mfl alleviates this condition, but it returns later. Steps to Reproduce: 1. About 1/7th or so of the times that I launch mail (with auto-login enabled), we fail to make a selection of the Inbox (using IMAP). Expected Results: Mail should always select the Inbox and load contents into the message pane. Actual Results/Observations: When we fail to auto-select and loads contents in step #1, you are still able to select the folder afterwards. However, this doesn't become true selection. The following things occur: 1. You can only 'select' a folder in the folder pane once. 2. Double-clicking on the folder after selecting it once doesn't visually select it, but correctly loads a new 3-pane message window with that folder selected (highlighted) and the contents of the folder appear correctly in the message pane. 3. When you hit this bug, even the successful first time *paint* of the selection doesn't bring the folder's title in the window. 4. This selecting of the folder also doesn't load any contents in the message pane. 5. Oddly enough, I'm still able to successfully use content menus for these seemingly 'unselectable' folders. I'll attach a screenshot.

Another relevant detail: restarting the app works most of the time to restore functionality. Does fastload rebuild itself if it detects some sort of corruption? I'm still not 100% sure it's fastload, but it's a likely candidate.

You can set nglayout.debug.disable_xul_fastload to true and be sure. FastLoad files shouldn't be corrupted by anything but an unexpected Mozilla termination (crash, e.g.), in which case the header's file size and checksum will both be wrong, causing a transparent cleanup on next start. /be

Brendan, I highly suspect Fastload now. I've changed that pref's value, crashed numerous times, and haven't had any problems. Previously, I was seeing problems with the 3 pane window on average 1 out of 7 times launching. I've been testing various crashers in mail/news on the trunk (with Fastload enabled). Perhaps the cleanup isn't as fortified as it could be.

It's hard to see how the fastload file's header file-size or checksum could be correct -- they're not written until the update to the file is done. I rather suspect that the code that removed the invalid fastload file is leaving some bad state in memory during the next session. Can you run a debug build, force some crashes, and save the Invalid.mfasl files that the session after then crash should save at startup? Then with your DEBUG build tree and a debugger, I can perhaps make some sense of things. /be

Another note about this bug: it's definitely per-window. If I close the window that is horked, and open mail/news again, this is fine. (This goes along with my earlier comments about double-clicking a folder to open in a new 3-pane window completely working).

here's another way to reproduce this: mozilla -P foo -addressbook from addressbook, open mail. that was making it happen for me nearly every time.

bumping up in importance.

reassigning to brendan based on the comments in this bug. Brendan, if you think this is mailnews code, please reassign back.

Look, I can't reproduce this, and after stephend and I talked it became clear that his problems were not all FastLoad-related. Can someone come up with reproduce-by instructions that make the symptom appear when FastLoad is enabled, and never when it is disabled? /be

reassigning to sspitzer. Stephen, can you help get Brendan the info he needs?

not mine...

donner, do you ever see this when switching between mozilla and netscape builds?

Seth, I haven't seen this in ages, and I don't believe Navin has, either. I suggest WFM, since nobody knew the problem anyhow.

marking WFM based on donner's comments.

verified.