Mozilla/5.0 (Windows; U; WinNT4.0; en-US; 0.8.1) deleting a message - selection doesn't go to next message
Confirming. This may be a duplicate, but I am not sure. However, it ain't severity:critical - that's for sure; downgrading to normal.
Severity: critical → normal
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows NT → All
change qa contact->myself, cc esther
QA Contact: esther → sheelar
What build? This is working fine for me on 2001032704 on Win 2000.
using today's build 2001-03-27, imap server, "mark as deleted" is selected BTW, it would be nice if Help-About showed the build date (bug 73745)!
*** Bug 73744 has been marked as a duplicate of this bug. ***
Status: NEW → ASSIGNED
Priority: -- → P3
Summary: deleting a message - selection doesn't go to next message → [mark as deleted] deleting a message - selection doesn't go to next message
Target Milestone: --- → mozilla0.9
change qa contact ->karen
QA Contact: sheelar → huang
Whiteboard: perf → perf,[nsbeta1+]
Target Milestone: mozilla0.9 → mozilla0.9.1
*** Bug 74704 has been marked as a duplicate of this bug. ***
I have noticed another problem caused by this bug that raises the severity a bit: Since there is no visible feedback when mozilla is done processing the deletion (the red x aparently does not indicate completion), when one deletes a msg and shortly after (1-2 secs) manually selects the next msg, it can happen that the next msg becomes undisplayable (it's selected but the message doesn't show). One has to restart mozilla to read that next msg. Sometimes i even had to delete the *.msf files in my imap folder - pretty serious stuff ;)
I looked into this bug but don't have a fix. There are two problems that I can see. The first is easy. In nsImapFolder it doesn't appear to send a HandleMsgDeleteOrMoveCompleted event in the MarkAsDeleted case (it does this for a move though). The second problem is that the code that determines the next message to select always chooses the first index in the selection to be deleted. This is under the assumption that the new selection will now be that position which works for the cases where messages disappear on delete (move to trash or delete immediately). However in the case where the messages don't disappear (Mark as Deleted) it just leaves it on the message being marked as deleted. So, in this case it actually has to choose the next message. In 4.x, Mark as Deleted would select the next message in the case of single deletion and leave the current selection in the case of multiple deletion.
Personally I like the new behaviour :-) Especially when I have already read (or a filter has already deleted) the next (or previous, if there is no next) message. Would it be too much to ask for a pref: Don't move/next/next unread?
reassigning to self, working on a related fix so will fix this also.
Assignee: sspitzer → naving
Status: ASSIGNED → NEW
For ImapDelete when we have multiple selection, we just clearMessagePane otherwise we increment the current selection by 1, because the message stays in the thread pane.
I don't think this is the way to fix this - getfirstselected should return the first message selected, no matter what the delete model is. This fix shold be in the code that figures out what to select after a delete.
sr=bienvenu. Note that we're not doing anything if there's a multiple selection and the user does a delete - which is probably ok.
fix checked in.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
*** Bug 73755 has been marked as a duplicate of this bug. ***
Verified on all the platforms: Win 05-02-12-trunk Linux 05-02-08-trunk Mac 05-02-09-trunk builds Marking as verified.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.