If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

message advance after delete too slow

RESOLVED DUPLICATE of bug 268098

Status

Thunderbird
General
RESOLVED DUPLICATE of bug 268098
13 years ago
12 years ago

People

(Reporter: Michael Thome, Assigned: Scott MacGregor)

Tracking

({perf})

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

13 years ago
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.

Updated

13 years ago
Blocks: 91351
Keywords: perf

Comment 1

12 years ago
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 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.