48086 - After Delete or Move, next message is not selected/loaded

Status: VERIFIED FIXED

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

Description

[fenella]

Linux (2000-08-08-08 M18)
Win32 (2000-08-08-09 M18)
Mac (2000-08-08-11 M18)
1. Launch Messenger
2. From my IMAP account, Inbox (or any other folder), select a message
3. Click on the Delete button.
Actual result: The hight-lighted message got deleted, but high-light focus
disappear. The Delete buttom is de-activated
Expected result: After Delete, the high-light focus should go to the next
message and the Delete button should be activated, so that I can choose to keep
deleting the next high-lighted message.

This occurs on Mac and Linux only. It consistently occurs on Linux
Win 32 has no problem.
It only occurs in IMAP accounts. POP account is OK.

Comment 1

[fenella]

This bug needs more observations...
I exit and re-launch Messenger on Linux, the problem seems to have gone away.

Comment 2

[lchiang]

Win32 2000-08-09-09-m18

I'm seeing this.
1)  Select a mail message
2)  Delete it or move/file it
3)  The next message does not get selected and displayed in the message pane.  
Instead, the message pane displays the previously selected message.  The thread 
pane doesn't have any item selected since the previous message was actually 
deleted and cleared from the thread pane.

Note: I am sorted by date.

Comment 3

[Chris Waterson]

Attachment: remember to remove from XUL doc's ID hashtable

Comment 4

[scottputterman]

It looks like this patch fixes this bug as well as any other bug where reloading 
a folder loses selection including sorting and threading.

BTW, the easiest way I could reproduce this bug was to delete the last message 
in the folder and then try to delete other messages.

reassigning to waterson.

Comment 5

[lchiang]

adding mailtrack.  Since this is now waterson's bug, I can't add nsbeta3+ to it.

Comment 6

[Chris Waterson]

Attachment: better fix

Comment 7

[Chris Waterson]

rjc: could I get you to review the patch to the template builder? When I fixed
the "search dialog gets stealth content" bug, I forgot to add code to keep the
XUL document's GetElementById() hashtable in sync. This code does that.

Comment 8

[Robert John Churchill]

Looks OK to me.  r=rjc

Comment 9

[Chris Waterson]

fix checked in

Comment 10

[fenella]

Linux (2000-08-16-09 M18)
Win32 (2000-08-16-10 M18)
Mac (2000-08-16-10 M18)
This problem has been fixed.