198364 - auto advance on delete to next unread mail message is broken with recent cvs since 20030319

Status: RESOLVED FIXED

(SeaMonkey :: MailNews: Message Display, defect)

Description

[Mitch]

User-Agent:       Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4a) Gecko/20030320
Build Identifier: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4a) Gecko/20030320

Previous mozilla cvs builds since 20030319 had the feature of auto advancing
to the next unread mail message once the current one had been deleted.
This feature is now broken (regression) since 20030319 cvs.

Reproducible: Always

Steps to Reproduce:
1. Click on a unread mail
2. Delete it


Actual Results:  
Mail selection stayed on deleted email (i have "mark message as deleted"
option turned on in Mail & Newsgroup->Server settings preferences)

Expected Results:  
The mail selection should move to the next unread email as it did previously

Regression

Comment 1

[Mitch]

I note that this could be an unfortunate side effect of the checkin
for bug 142065 that was checked in on 18th (i.e. ever since this started
happening)

Comment 2

[Calum Mackay]

Confirmed, for the last week or so.

I fear this may be intentional behaviour. I know there's been requests for this
from people who don't want to advance to the next message - with the side-effect
of marking it read when they didn't want to read it, so having to then mark it
unread.

I had hoped it would be configurable though...

Comment 3

[Calum Mackay]

Re my comment 2, see also bug 65823.

Comment 4

[Mitch]

I agree, this should definetly be a configuration option. After several years
of this behavior with both mozilla and netscape (and other mail agents) a
MAJOR change in the UI should not be taken so lightly without a vote or a
user configurable option.

Comment 5

[Peter Lairo]

I sure hope making it this way was NOT intentional. 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, 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. :(

Comment 6

[Ken Snider]

I'm going to vote this be marked a dupe of bug 65823 - that bug is about delete
not skipping forward as an RFE, this bug is about how delete was skipping
forward but ceased - however bug 65823 has evolved somewhat into a discussion of
how to make this an option.

Seth?

Comment 7

[Mitch]

Agreed. This bug should be marked as a regression in behavior and
bug 65823 marked as an RFE with an option to enable it.

Comment 8

[Gervase Markham [:gerv]]

Reading the patch over in bug 142065, I'm pretty sure ssu broke this :-)
Reassigning to him, and nominating as blocking1.4b. This is really irritating
from a usability point of view; it really makes the interface feel clunky.

(If I select a message and delete it, the one message you can guarantee I
_don't_ want to be reading is the current one. Moving to the next message, the
previous behaviour, would be OK; moving to the next non-deleted one would
probably be better (bug 65823) - but I'd settle for a return to how it worked
before.)

Gerv

Comment 9

[Sean Su]

Attachment: patch v1.0

Here's a patch that seems to fix this.	I'm still testing other permutations of
'delete message'.

Does anyone know (in the 'Mark It As Deleted' delete type):
 * if deleting the currently selected message loads the next unread message or
simply the next message?
 * if selecting multiple mssages and deleting them will load the next message?
 * if undeleting the currently selected message loads the next
'message'/'unread message' at all?

I'll try to find the answer with a build that used to work.

Comment 10

[Sean Su]

Here's what I found out what it did before:

  * if deleting the currently selected message loads the next unread message or
simply the next message?
 -> It simply loads the 'next message' regardless if it's read or not and
already marked as deleted or not.

  * if selecting multiple mssages and deleting them will load the next message?
 -> It does not load the next message.  It keeps the selected messages selected.

  * if undeleting the currently selected message loads the next
'message'/'unread message' at all?
 -> It does not.  It leaves the currently selected message loaded.

I just tested the patch, and it will restore all of these behaviors, along with
fixing this bug.  It will also not regress bug 142065.

Comment 11

[Gervase Markham [:gerv]]

All the previous behaviours are as you describe. Excellent :-)

Gerv

Comment 12

[Gervase Markham [:gerv]]

Comment on attachment 120212 [details] [diff] [review]
patch v1.0

Wow, you guys use longwinded method names in MailNews :-) r=gerv, although you
might want to fix that extremely long line to fit in 80 chars. This seems sane
to me, although I'm not in a position to test it.

Gerv

Comment 13

[Sean Su]

Comment on attachment 120212 [details] [diff] [review]
patch v1.0

Seth, basically, the patch just adds a check for:

+  if (treeSelection.isSelected(treeSelection.currentIndex))
+    gNextMessageViewIndexAfterDelete = gDBView.msgToSelectAfterDelete;

if the deleted message is the same as the hilighted message, then we should use
the normal way of determining what the next message should be via
gDBView.msgToSelectAfterDelete (as it did before).  Not sure why was taken out
in my other patch, sorry.

Comment 14

[(not reading, please use [e-mail] instead)]

Comment on attachment 120212 [details] [diff] [review]
patch v1.0

looks reasonable, and 
ssu is good at testing his stuff out.

r/sr=sspitzer

Comment 15

[Sean Su]

patch checked in.

Comment 16

[Doogie Brodie]

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

Comment 17

[(not reading, please use [e-mail] instead)]

clearing 1.4b request, since the fix is in.