156699 - keyboard multi selection fails.

Status: RESOLVED FIXED

(SeaMonkey :: MailNews: Message Display, defect)

Description

[Judson Valeski]

I just repro'd this on yesterday's 1.0.1 build, win2k.

This has been the longest standing multi selection bug for me personally. I
finally found a repro case.

problem:
When using the keyboard to navigate the mail header pane (threaded view), I can
get into a state where shift-arrow (for multi header selection) loses selection
on the initially selected single item, skips the 2nd item, and ultimately kicks
in on the 3rd (and works from there on... 4th, 5th, etc are selected).

steps to repro:
1. Open mail news header view
2. select the top message in an unexpanded thread.
3. using the right arrow key, expand the thread.
4. walk down the thread reading each message (a thread of two is enough)
5. once at the bottom, hold the shift key down, and walk back up the thread
using the up arrow key to select all the messages in the thread. This will work
just fine, the problem comes later.
6. Once all the thread msgs are selected, delete them w/ the delete key.
7. Now you're back to a single msg (threaded or not) selected in the header pane.
8. At this point, multi selection is broken. hold the shift key down and arrow
up or down and notice that a) the initially selected message loses selection, b)
the next message you arrow to does not select, c) the 3rd message finally picks
selection back up and things work great from there.

expected results:
shift-arrow for multi selection works properly after deleting the thread.

Comment 1

[Olav Vitters]

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

Comment 2

[Judson Valeski]

I'm seeing this in yesterday's 1.1 (not 1.0.1) build as well. win2k.

Comment 3

[[e-mail]]

This happens because the tree is still in multiselect mode when you delete the
messages from it, but the deletion doesn't change the current index (assuming
you're not using IMAP mark as delete) so the tree thinks your selection is still
active when it isn't, thus extending the selection produces strange results.
If my evaluation is correct it should apply when you delete any range of
messages selected upwards, they do not have to be threaded.

Comment 4

[[e-mail]]

My patch to bug 97434 should have fixed this; the backend code was all in place
but the front end code was incorrectly duplicating the work.