User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20040914 Firefox/0.10.1 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20040914 Firefox/0.10.1 deleting the current message advances to the next message, but only after the message has actually been deleted. Trying to delete multiple messages on a slow imap/pop connection can result in the wrong set of messages being deleted. A better design would be to advance to the next message *before* the server/background-thread interaction - basically, the UI should generally never be dependent on server operations, but rather should queue work for the server interation thread to execute on. Reproducible: Always Steps to Reproduce: 1. open a pop/imap folder with messages to be deleted 2. select a message near the top 3. hit delete (say) 6 times in rapid succession. Actual Results: <= 6 messages will be deleted Expected Results: exactly six messages should be deleted.
This matches what I was about to put a bug report on. I am continually getting burned by Thunderbird failing to delete the items that I tell it to. 1. I hit delete "fast" several times in succession. 2. TB implies it is immediately deleting all the items I told it to but making them dissapear before my eyes 3. TB then refreshes, all the deleted items re-appear and then collapse down as it "really" deletes them 4. TB doesn't delete all of them. So I end up with some left over and have to delete them again This is with an IMAP backend (not over SSL) Note that this is probably most noticable on high-latency links. I *think* this problem is worse when (say) I'm in another country accessing my IMAP server. I'm guessing there's a GUI presentation component, plus a backend component, plus a confirm-the-two-components-match-up component - if you follow me :-) This is with TB 1.06 under Fedora Core 3
*** This bug has been marked as a duplicate of 268098 ***