Closed Bug 76501 Opened 24 years ago Closed 24 years ago

multiple imap msg delete results in multiple msg load

Categories

(SeaMonkey :: MailNews: Message Display, defect, P1)

x86
Windows 2000
defect

Tracking

(Not tracked)

VERIFIED FIXED
mozilla0.9.1

People

(Reporter: Bienvenu, Assigned: Bienvenu)

Details

(Keywords: perf, Whiteboard: [nsbeta1+])

If you delete multiple messages, we attempt to load one or more of the deleted messages before loading the next non-deleted message. If you watch the header area of the message pane, you can observe this. I don't know if this is limited to imap or not.
adding keywords
Status: NEW → ASSIGNED
Keywords: nsbeta1, perf
QA Contact: esther → sheelar
marking nsbeta1+ and moving to 0.9.1
Priority: -- → P1
Target Milestone: --- → mozilla0.9.1
Whiteboard: [nsbeta1+]
This has to do with the way we load messages in the nsMsgDBView::SelectionChanged method when the selection goes to one. When you delete two messages (for example), we send a notification that the first message has been removed; this causes the outliner to tell us the selection has been reduced to one, so we load the one message. It gets immediately deleted, and the selection goes to 0. Then, we load the next message after the delete from the front end. I initially was going to fix this by making the view a copy listener, and turning off the selection msg loading during a msg move/delete. Unfortunately, the end copy notification happens after the notification to load the next message after delete, so it's not that easy. The approach I'm considering now has to do with batching the delete notifications to the outliner, so that we tell it about range deletes, which will speed up delete in general, and reduce the chance of doing the multiple message load. However, this won't be sufficient in the case that the selection is not contiguous, so I'll still need to worry about that case too.
fix checked in
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
I did not see deleted or mssg selected to be moved in imap or pop that gets loaded in the process before the next non deleted or moved mssg in the thread pane gets selected. Honestly, I was not able to reproduce this behavior in the previous builds. Verifying this bug since I still don't see the behavior reported. buildid: 2001050706win98, 2001050708 linux, 2001050706 mac
Status: RESOLVED → VERIFIED
you have to look closely at the message header area, and maybe be on a slowish machine. But thanks for verifying it!
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.