If you collapse the message pane in the 3-pane, then switch tabs, then switch back, the message pane will no longer be collapsed, but will no longer update. When you hit F8 again, the message pane will immediately update (and not collapse), so the problem is likely due to makeActive not properly setting the state of the message pane when the 3-pane tab is returned to. This probably got lost in the move of the logic from mailWindowOverlay to folderDisplay/messageDisplay.

Not only with tab switch but also on selected folder change.

Also on Shredder relaunch: If I collapse the pane in one session, then close, then reopen, the pane is back, and it also marks messages unread in that state, as if it was showing something.

This started, at least on windows, after the June 12th nightly.

My test case is: - open Thunderbird - go to Inbox - disable message pane (F8 twice) - go to another folder - the message pane is back This particular thing makes Thunderbird unusable in "no message pane" mode. IE the only way the current nightly build can be used is with the message pane on.

Besides making the message pane reliable, this also implements tab persistence as desired by bug 459096. This was done because the previous RDF XUL attribute persistence stuff did not know what tricks we might be doing with tabs. Also, we wanted tab persistence. Ideally sid0's patch on bug 467768 will land first and rot this slightly, but this currently applies to trunk and passes all folder-display mozmill tests. This should layer on top of the current bug 474701 gloda search layer with only a single hunk fuzzed, although that was with 3-line context, and the patch I'm providing has a full 8... you might need to import it, refresh it, then re-order your queue to get that going on if you so desire. Be forewarned if playing with tab persistence that because it opens every tab in a foreground tab in a very rapid fashion, weird things can happen with message streaming when a message tab is involved. We will be able to mitigate this once bug 467768 lands by opening message tabs in the background.

I ended up having to apply a couple parts of the patch by hand, so I may have screwed up. But I ran with this on top of the gloda search layer patch. I did lose all my folder expand/collapse state, but that may be because I ran with a bogus merge first. Right click on a non-selected folder, and open in new tab, does *not* open the right clicked folder in the new tab - it opens some other folder, usually, though I'm not sure how it picks a folder. Occasionally it shows account central. (maybe not caused by this patch, or the gloda search layer patch, but I'm kinda grumpy about having to apply all these chunks by hand, so I'm mentioning it here :-) ) At least for me, this is pretty common way to open a folder in a tab. mozmill test hung, though I strongly suspect that sid0's patch in bug 467768 will help, since the double message load seemed to produce a fair amount of unhappiness. This was with a debug build.

Comment on attachment 385044 [details] [diff] [review] fix message pane issues, implement simple tab persistence, add mozmill test v1 modulo the right click open folder in tab issue, and assuming the mozmill test will get happier with sid0's patch, r/sr=bienvenu.

mozmill test screen shot: http://www.grabup.com/uploads/73002522061920092A1769309C07.png

Wow, if you sometimes got (another) folder opened for non-selected, that's a step up from bug 498155.

(In reply to comment #9) > I ended up having to apply a couple parts of the patch by hand, so I may have > I'm kinda grumpy about having to apply all these chunks by hand, so I'm I feel your pain. I'm going to pursue using pbranch or something else for all my new patches. The inability to know what revision a patch should be applied against is problematic for reviews. Not to mention the situations created where you are trying to base your patch off someone else's in-progress patch.

pushed: http://hg.mozilla.org/comm-central/rev/781f622cb9b7 The mozmill test passes locally. I'll spin up the mac mini and see if I can get it to choke. I don't have the endurance to try a build in my windows VM, but maybe I'll spin something up on my personal windows laptop.

No longer comes up or empty unexpectedly for me in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1pre) Gecko/20090626 Shredder/3.0b3pre

I have this problem on the release version of Thunderbird 3. Problem: Message Pane does not stay disabled. Disabling message pane results in it's removal for the current session. After one or two restarts of the PC, the Message Pane will be re-enabled when Thunderbird starts. Version information: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0