522434 - Deleting from standalone message window doesn't move to next message

Status: NEW

(SeaMonkey :: MailNews: Message Display, defect)

Description

[Peter Weilbacher]

Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.5pre) Gecko/20091014 SeaMonkey/2.0pre

With this SeaMonkey I notice that when I have the standalone message pane open and delete the current message from there, it only toggles the deleted state of this message. But the selection does not move further to the next message in the list as was the case with nightlies a few days ago.

This reminds me of bug 514876 (so, Karsten, maybe you have an idea?) but so far I haven't found out what change caused it this time, but it must have been before the 20091013 nightly, which was affected, too.

Comment 1

[Karsten Düsterloh]

Is mail.close_message_window.on_delete really set to true?
I fixed 519128 just two days ago...

Comment 2

[Peter Weilbacher]

No, mail.close_message_window.on_delete is false. But the window doesn't close when using delete, I can just see the message getting marked deleted in the Thread Pane. (Before the recent change, the message was marked deleted but the contents of the standalone window were filled with info and body from the next message in the list.)

Comment 3

[Robert Roessler]

WFM (superficially) on both the 20091013 and 20091015 nightly SM 2.0pre builds (Win7 x64).

When viewing a message in a standalone window, if I delete it (using the Delete key), the message IS removed from the Inbox thread pane, and the standalone window contents ARE replaced with... something.

There may be problems here - but for me, they are not the ones reported by Peter.

The message selected for display after doing the delete seems to be merely the next message in the thread pane, irrespective of its "read" status - and since I use the "newest at the top" sort, this means it shows the "previous" message.  IOW, it emulates the "F" command rather than the "N" command.

While I think the "N" command behavior is more intuitive, that may just be personal preference.

However, a real problem is the fact that the undo/redo delete message information is not being maintained when deleting a message from a standalone viewing window, i.e., I do NOT get a "Undo Delete Message" entry in the Edit menu.

In any case, I really hope that nobody wants to back out the fix for Bug 519128, as a large amount of the SM email reading functionality has been restored by that fix! ;)

Comment 4

[Peter Weilbacher]

I guess the difference between my setup and Robert's is that I have mail.server.server<N>.delete_model 0 ("Just mark it as deleted") set for all my accounts. I think the default is 1 ("Remove it immediately").

Comment 5

[Robert Roessler]

I just checked, and I do not have a per-server variable like the above at all... but I do have a non-server-specific var called mail.server.default.delete_model, which says it has a default value of 1.

Comment 6

[Karsten Düsterloh]

The main point here is "IMAP Delete Model".
When Magnus "fixed" bug 486954, the selection change after mark as deleted worked, but only by chance. When I restored the old behaviour in bug 519128, this broke again.
The problem is that OnItemRemoved isn't called in the mark case, because the mail isn't really removed...
I'll try to find a better fix.

Comment 7

[Karsten Düsterloh]

Or rather: the question is whether mark as deleted should behave like a real delete in terms of notifications. Looking at the code in <http://hg.mozilla.org/comm-central/annotate/b887790ca1f2/mailnews/imap/src/nsImapMailFolder.cpp#l2340>, it suggests that the FE should not be notified of this (at least not as DeleteOrMoveMsgCompleted), so the current behaviour of not switching the message would actually be correct - it does behave like other mark actions (mark as read, mark as junk without moving).

David, do you remember the intended behaviour?

Comment 8

[David :Bienvenu]

I think that code does send a DeleteOrMoveMsgCompleted, if I'm reading the braces correctly. I think delete in the stand-alone msg window, even in the imap delete model, should advance to the next message, personally, but I don't use the stand-alone msg window.

Comment 9

[Karsten Düsterloh]

(In reply to comment #8)
> I think that code does send a DeleteOrMoveMsgCompleted

Yes, it does; sorry, I meant that NotifyMsgsDeleted/OnItemRemoved is not called for a mere mark, only for real deletes in line 2350...

Comment 10

[David :Bienvenu]

Yes, that's on purpose - imap delete really is just a flag change.

Comment 11

[Peter Weilbacher]

So you are saying this new annoying behavior is as designed and this bug WONTFIX?

Comment 12

[Karsten Düsterloh]

(In reply to comment #11)
> So you are saying this new annoying behavior is as designed and this bug
> WONTFIX?

No, "I'll try to find a better fix." still holds, it's just not as easy as I thought.

Comment 13

[Robert Roessler]

Good luck with the "better fix" thing... but please note comment #3.

Also, how did you come to the conclusion that this bug has anything to do with IMAP (your comment #6)?  Or does it?