I can reproduce the bug for weeks now, using Tb 2.0b1pre (I'm now running Tb version 2 beta 1 (20061114)): When I'm reading new emails (mainly in my POP3 gmail.com account. I didn't really check with IMAP accounts) and I'm deleting some of them (those I don't want to keep), Tb sometimes compacts the folder to spare some space on the HD, as expected, but this action removes the focus from the selected message in my list (the top right panel) and the top of the list is displayed in the panel, instead of only deleting the message and displaying the next one. So I have to scroll down again, find the next email to read and click on it. This is clearly a regression (don't ask me any time window, I really don't remember) as this didn't happen in 1.5.0.x.

This is working correctly in the trunk (3a1-1128). I reproduced the symptom once with 2b1-1122, Win2K, using right-click, Compact. I've tried again several times and can't make it occur again.

The problem is not when compacting folders manually, but automatically. I know Phil sees this bug too (per his comment on IRC yesterday).

And I do see it on trunk, though I haven't set the threshold low enough, and given myself enough crud to delete, to have looked at it in detail yet.

I have the same problem, using TB 3 alpha 1 (auto-updated almost every day). The option "Compact folders when it will save over" is set to 100 KB. Every time the auto-compacting is triggered, the current message loses focus, whether in the reading pane, or a separate window.

When we manually compact folders, inn MsgCompactFolder we save off the currently loaded message in gCurrentlyDisplayedMessage: http://lxr.mozilla.org/mozilla/source/mail/base/content/widgetglue.js#171 In HandleCompactCompleted, we load the currently selected message using the saved off value of gCurrentlyDisplayedMessage. When we automatically compact folders, we don't go through MsgCompactFolder so gCurrentlyDisplayedMessaged doesn't get saved off.

I'm not convinced this is the right solution yet. Will keep investigating.

that seems like the right idea - gCurrentlyDisplayedMessage is an index, so it survives compaction. Do we need to still do this in MsgCompactFolder? Seems like if this works, we might not need to.

MsgCompactFolder clears the thread pane which clears gDBView. But maybe it doesn't need to clear the thread pane. I'll keep poking.

Comment on attachment 248698 [details] [diff] [review] possible fix Let's try this then. We could remove the code in MsgCompactFolder if we also had it stop clearing the thread pane, but it sounds like it is safest to leave that alone.

Phil and others, would be good to get some feedback on how well this fix is working for you.

Near as I can tell, on trunk/Mac, it doesn't work at all. I might be missing successes, since I'd expect them to just be a flash of the statusbar, but it sure looks like it fails to reselect every single time.

re-opening per Phil's comment. Maybe gDBView is already null in the automatic folder compaction case too...Hmmm...

Is this related to bug 271988? That has a specific and easily reproducible cause: right-click on a different folder than the selected one and pick Compact.

I second what Phil said. The problem still exists with today's nightly build.

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

yes, I see this with the automatic prompt, but not when you explicitly pick file | compact folders. I'll try to see what's different.

the problem with the autocompact stuff is that it's triggered from the backend, so the front end js never gets a chance to save off interesting information, or to even blank out the thread pane. I really need to trigger the front end from the backend - maybe by sending a notification event?

for the autocompact case, I had to make two changes: issue autocompact *after* we've done the delete which causes the next message to get selected, so we don't think the currently loaded message is the deleted one. notify the front end the compact is about to happen so it can save away the current message to display.

Comment on attachment 250973 [details] [diff] [review] proposed fix We should back out my change to msgMail3PaneWindow.js for this bug when this lands too.

I backed out the earlier patch as well.

Looks like your fix doesn't work. The problem still happens.

Odd, it works perfectly for me, with Mac/trunk.

Yeah, maybe it was because the nightly I downloaded didn't have the fix yet (I took it a few hours after david checked his patch in). I downloaded the very last nightly and it seems to works fine now. But I noticed that deleting a message in a thread didn't select the next message of the thread when auto-compact occured, but the first message of the next thread. I didn't pay any special attention, though. I just saw it once... 2 minutes ago.

flag cleanup. this is already on the branch.