264951 - message advance after delete too slow

Status: RESOLVED DUPLICATE of bug 268098

Description

[Michael Thome]

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.

Comment 1

[Jason Haar]

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

Comment 2

[Wayne Mery (:wsmwk)]

*** This bug has been marked as a duplicate of 268098 ***