After deleting a message, the seletion should move to next NON-deleted message. For imap servers, when prefs are set to "Mark as Deleted" and one deletes a message, the selection should move to the next NON-deleted message and not just to the next message in the inbox, even if that message was already marked as deleted. If there is no next NON-deleted message, then the selection should just move to the next message (even if it is "marked as deleted".

Personally I think the selection should move to the next unread message. Of course this relies on mail filtering marking deleted messages as read.

change qa -> karen-IMAP model

*** This bug has been marked as a duplicate of 79998 ***

Verify as dup.

NO, not a dupe. The other bug is about the selection highlighting staying on the subj line of the last visible msg AND another selection highlighting on the actually selected msg. This bug is about the selection moving to the next *non-deleted* message. reopening.

The current behavior is that after selecting multiple messages, after you hit "delete" the selection jumps way down to the bottom of the list, scrolling away the messages you were just looking at. This is horrible astonishing UI that essentially yanks control away from the user (much like cursor warping, yuck). If it moved to the next message, deleted or not, then the user would not lose his scroll context (would not have to scroll all the way back up just to see the messages he was just looking at). Or, the next non-deleted message would work too, but would still have the potential to startle and annoy the user, so my vote is for a simple "next message, deleted or not." OTOH, if it moved to the next unread message, then the potential exists for more astonishing behavior (scrolling several pages down, again losing the scroll context), so the behavior should be as proposed (next non-deleted). The "next unread" behavior would make sense if the user were in the process of reading new messages, but when selecting multiple messages for deletion, he's probably going back and cleaning up his inbox, so doesn't care about the fact that a message is unread.

*** Bug 114633 has been marked as a duplicate of this bug. ***

Nominating nsbeta1 since deleting msgs is the basic functionality for mark as delete mode.

*** Bug 89394 has been marked as a duplicate of this bug. ***

*** Bug 117900 has been marked as a duplicate of this bug. ***

*** Bug 115950 has been marked as a duplicate of this bug. ***

sometimes the selection jumps, from top of the thread-pane to last msg. we should fix this also.

*** Bug 120773 has been marked as a duplicate of this bug. ***

navin, isn't this a dupe of http://bugzilla.mozilla.org/show_bug.cgi?id=115950 ?

ok, sorry for spam, didn't read the obvious comment #5, argh..

IMHO this is not that minor (and it does have 4 votes).

Another aspect: When the selection moves to the next message and this message is already deleted, at least it shouldn't remove the deleted-mark of this message!

What about increasing the scope of this bug - instead of moving to the next NON-DELETED message, what about leaving the selection in place - marking the message as deleted and doing nothing else? This is the default behaviour of Outlook / OExpress when you mark an IMAP forder message as deleted, and do not move it to the trash

> instead of moving to the next NON-DELETED message, what about leaving the selection in place Definetely not. I routinely "move" through my inbox by deleting mails and reading the next one. It would be _extremely_ tedious reading mails with your suggestion. (Only *after* I'm sure I haven't deleted something I want to keep, do I select "compact folder".) BTW. Just _because_ OE does something one way is _no_ reason to copy the behavior.

Then it should be an option, hm? After deleting a message [ ] Stay on deleted message [ ] Move to next message [ ] Move to next non-deleted message [ ] Move to next non-deleted, unread message How hard is it to add options? (And if it is hard, why? And how can we make it less hard?) (BTW, I don't see a real use case for that last option (skipping over read messages) which is IIRC how it works now.)

I can't believe I'm about to say this ... (I'm a *big* advocate of options) Just because something is _possible_ doesn't mean it should be an _option_ . If there is _one_ way that makes the most sense (and the other "possibilities" are not nearly as relevant), then doing it _one_ way is sufficient. To adress your suggestions (possibilities): 1. No. Why would most users want to stay on a deleted message? 2. No. A user is unlikely interested in re-reading a mail that he had already deleted. Therefore skipping over it makes the most sense. 3. YES That is what this bug is requesting (move to next non-deleted message). 4. No. This seems to make sense, BUT often users will down-key through messages to get to one further down, thus often marking the skipped ones as read. Then, when reading the rest of the messages, it would skip all (supposedly) read mails. BTW. "How it works now" is #2. ;)

For the record: I think the duped bugs in comments 7, 9, 10, 11 are really different bugs. They pertain to the selection jumping way down after deleting _multiple_ mails at once. However, if this bug _also_ fixes that odd behavior, then GREAT.

> BTW. Just _because_ OE does something one way is _no_ reason to copy the behavior. This is true, however it *is* a reason to provide the option. One of the problems I (and the Outlook/OE users I'm trying to convert) have with Mozilla as it is now is that it will move to the next message and mark it read, immediately - whether or not it has actually been read. Not everyone reads all of their messages immediately - I for one receive a ton of mailing list messages and bugzilla notices, which I may choose to read before, or after other mail. I use the "unread" state of these messages in my IMAP folder to determine whether they require my attention or not (or if they have been read or not). Oftentimes these messages are interspersed with other emails, ones I do not yet wish to read, and find myself marking messages "unread", rather than read. Regardless of *why* I choose to read my mail one way or another, the point is, the option should exist - when a message is *un* deleted currently, no change to the message selection takes place - the message simply removes it's "delete" flag. I'm asking for the same behaviour when you delete a message. Mark it deleted, do nothing else.

Further to my last post: I went around the office asking people that very question. Why do you *like* not moving on to the next unread message? The answer, almost unanimously, was this: "Simple. if I didn't want to read the next message, yet I want it to stay UNREAD for next time, then I want it to stay on the message I just finished with. Reading the next message marks the message as READ, and that sucks :)" Simply, if you delete messages you read, then you can't actually STOP reading new messages until you hit the bottom of your mailbox, without marking that message *unread* after it skips forward. In a way, we're forcing users to read all their mail at once, or risk having the unread flag removed and missing email.

That's especially important of course for users who have "view->unread" as their normal view. In addition, if the next msg is 10MB, and I'm working from home over a 40kbit PPP modem connection, I don't want moz to start downloading it. I'd like the option.

OK, I see your point about the next message being marked "read" and that possibly causing users with "view / unread" (honestly, how common is that in MAIL ?) to think they already read that one mail. However, IMO the convenience of easily being able to click-delete through and read several mails outweighs the last mail being marked "read". BTW Most know that just because it is *marked* "read" (unbolded) does *not* mean it *was* read. Also, try pressing "m". PS. A good _filter_ would help you group messages by what you read at once (or read later). ;) PPS. You don't have to wait for Moz to download the entire (large) message. Press "stop" or click on another message.

I agree. One-click-read-via-delete is a useful option. This is why IMAP mailers like PINE offer the options "delete-will-advance" and "delete-skips-deleted". However, the default is still to just do what you asked it to do, mark the message deleted, and do nothing else. There needs to be options for both. In fact, the two options listed above would cover all cases, I think, if the default was to simply mark a message as deleted, and perform no forward motion in the selection.

Agreed that view->unread is unusual, I do use it on occasion when I get lots of wrongly dated emails, which of course moz sorts by date. Whilst we're on the subject, I see [related] odd behaviour when deleting a msg that isn't the current selection. If I select a msg, then right click on a different msg *above* the current sel, and delete, the selection moves one msg upwards the deleted msg. A bug, shurely? [It only happens upwards]

[RFE] is deprecated in favor of severity: enhancement. They have the same meaning.

Not sure if this is the correct bug to mention this, or if I should file another one. Usually you can delete spam messages without having to read them at all by using the context menu and selecting delete. However, with the imap-delete model, the spam message gets displayed right after you delete it! If this bug has the option to "stay on the deleted message", then the message should not get loaded.

Please update TM (1.2alpha is ancient history by now).

taking. I think this is what neil was talking about in http://bugzilla.mozilla.org/show_bug.cgi?id=188051#c12

I want to add my vote for delete NOT going to the next message. I like to control which message to read. I often skip messages on purpose (spam, not important, etc.) and do not like being forced to mark unread constantly.

Am I missing something, or did this change get landed? In the last few days builds I find that delete is no longer taking me to the next message. Is that a different bug?

Re my comment 34, see also bug 198364.

Something got landed which affected this, yes...

RE comment #33: The best way to resolve that scenario is the fact the the junk filter can move júnk mails to another folder, also, you could filter (most of) the important or unimportant mails to another folder. That way you wouldn't need to mark anything unread. Another reason to move to the next (NON-deleted) mail is that I typically hover my mouse over the DELETE button as i read my mail: 1. read message 2. press delete button - repeat With the current BROKEN behavior (selection stays on deleted message), I now have to: 1. read message 2. aim at delete button 3. press delete button 4. aim at next message 5. select next message - repeat The steps to perform this routine task have more than doubled! Even (unfairly) combining steps 2&3 and 4&5 it is a 50% increase in steps. :(

That doesn't solve the issue of choosing NOT to read a message now for any given reason, skipping it, then deleteing the message above it, while in "descending" mode (new messages on top). the selection actually moves *backwards* in this case. even if the message was read (or deleted!), it will still skip back to the previous message, not forward. That's the problem, those of us in this bug have had this issue you are now experiencing (having to manually position our selection) *because* the selection changes. However, both methods of reading are valid.. therefore, as I suggested, this needs to be an action controlled by a pref, rather than inposed one way or the other on users.

Mail triage team: nsbeta1-

I also don't like the automatic movement without the ability to control how it should move. I upgraded from 1.0 to 1.3 and things went bad: The selection moved after deletion and the new selected message was downloaded and dispalyed in the preview section. (With 1.0 there was simply nothing selected.) This is dangerous if the new message is spam, extremely until the feature "no Grahpics download in mail" has become the secure form "no automatic download of any kind under any circumstances when opening mails". Otherwise you confirm your address to the spammers as really activ in use.

RE comment #40: please read comment #37 before posting about junk mail.

RE 41: I know what's junk better than Mozilla. RE 40: Upgrade to 1.4a where this problem has been fixed.

The point of comment #37 is that the junk filter will so strongly reduce the amount of junk that accidentally jumping to a junk mail becomes less enough imortant or likely, so that the convenience of this bug becomes more important.

Does anyone have a patch to fix this? I see bug 198364 has the patch to create the broken (IMHO) behaviour. I don't know the source, but it affects a function called SetNextMessageAfterDelete which doesn't seem like something I'd want to call. So rather than attempt to modify that function, is there someone who knows how that function gets called when I press delete so I can have the option to not SetNextMessage at that time?

I have the problem where I delete a message, then go on to read another message, then I get yanked back to the mail after the message I deleted. Is that part of this bug or is that another bug?

I read the comments and as far as I can see nobody has mentioned another irritating aspect of this behaviour that I think is really the same issue, and that is the behaviour of the selection when you mark an email as junk. I'm using IMAP; don't know if this happens with POP. Suppose you have a message selected, and you use the junk column (not the junk button in the toolbar) to mark a message elsewhere in the list as junk. This is something I do all the time, when I'm tagging junk and don't need to even look at the body. Then the selection is jumped forward to one after the one you're tagging. In this case I assume the internal logic is: tag as junk, automatically delete; delete causes move to next message. But the message you were on is not the one you were operating on so the jump to next message is completely unexpected. The right behaviour in this case would be to leave the current message selection unchanged if the deletion was not to the current message selection. I think you could argue this aspect of the behaviour is a bug, so maybe I should create a separate report for it. However it's pretty clear part of the same behaviour as the rest of this one.

I would definitely prefer nothing else to happen when a message is deleted - no moving to other messages. I would be happy even if the option to change this was available in one of the configuration files instead of the main options. I'm using Thunderbird v0.4.

When I delete a message that I just read, I don't want ANY message to open automatically. I want to go back to the list. It really ticks me off when it opens a message without my permission. I am very happy that I can now mark a message as unread, though. On an older Mozilla, I was able to set an option somewhere so that it didn't open a message after I deleted one. Now using Mozilla 1.6/Mozilla 5.0 (what's up with the two version numbers?)

*** Bug 131760 has been marked as a duplicate of this bug. ***

I agree with comment #47 in that I would prefer that *NO* movement be taken when I delete a message. I often receive at least 20 messages a day that have slipped by Mozilla's junk-detection algorithm. What I will then do is quickly mark each message as junk since I can easily tell by looking at subject and sender. What ticks me off is that for every message I select as junk (and therefore gets deleted as per my preference) Mozilla will move my cursor to the next message, automatically opening a message I never wanted to see.

See also bug 200138, bug 262636 -- similar, but for the Junk Mail case.

Really need this option. It's already working like that in Evolution.

This bug persists in Thunderbird 3.0, albeit in a slightly different form. My selection moves to a _different_ message after a deletion. However, this message seems to be unpredictable. Sometimes it's earlier, sometimes later in my mail list. I reproduced it in the 2-17-2010 daily (latest available for Ubuntu Karmic). The only sane behavior is to move to the _next message in the list_. If you move to the nearest unread message, the nearest marked message, next longest message, whatever it is that the current behavior is, you break predictability. Then, I cannot quickly enter a sequence of "Delete" and "Down" keystrokes, deleting messages I don't want, and skipping the ones I need. In fact, I constantly end up deleting the wrong messages due to the current behavior. This bug is a showstopper for me.

contrast with bug 452394, which rather asks the opposite behavior