User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031227 Foxybird/0.7+ Build Identifier: Mozilla Thunderbird 0.5a (20031219) If a message on the pane is being viewed in preview mode, and a message above it is marked as spam and sent to trash or otherwise deleted by some means, the current selection moves down a message, for no good reason. Annoying when what's below is spam or something marked unread intentionally, and even just for the time it takes to display the new message. (Slow machine.) And when the current selection is deleted, the one immediately below is selected, when it seems more intuitive and less annoying to simply not show any message. (Perhaps an option?) Whatever the merits of the second, the first seems to be a bug, especially since if new messages come in while a message is previewed, the preview stays on the same message. Reproducible: Always Steps to Reproduce: 1. Open a message in the preview pane. 2. Mark a message above it in the list as spam. Actual Results: Preview switches to next message down. Expected Results: Keep preview on same message.
Um, hoping that this will no longer be listed as "unconfirmed" if I make a comment that it happens to me, too. I'm using XP; I suspect this is not at all OS dependent?
While I cannot (yet) provide a patch for this bug. It looks like what is occurring is that the message that is 'selected' is based more on the item number in the tree than the actual message itself. So basically, if your selected message is item 5 and you mark item 3 in the tree as spam, the selected message is *still* item 5 ( but it is obviously the message that followed the old item 5, which has now become item 4 ).. My suggestion is to put a bit of logic into the performActionOnJunkMsgs() function as this is what causes the marked junk message to be deleted and moved to the junk folder. This function (mistakenly) clears the currently selected message ( which is not the one that is being marked as junk in this case). The function then selects the message that *was* marked in order to delete and move it. Understandibly. A check should be made that the currently selected message is in fact the one that is being marked as junk, and if not, the current selection should be saved in order to then set the tree's selection back to this saved selection following the delete and move of the junked message. It's not easy as one would have to take into account the fact that the current selection might be several messages, contiguous OR non-contiguous AND that the saved selection's indices that come before the junked message would be one index off following the delete and move. It would probably be easier just to scrap the current selection and concentrate on what the last (one) selected message KEY was and .selectMsgByKey THAT message following the junk message delete and move.
*** This bug has been marked as a duplicate of 209748 ***