If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

keyboard multi selection fails.



MailNews: Message Display
15 years ago
13 years ago


(Reporter: Judson Valeski, Assigned: janv)


Windows 2000

Firefox Tracking Flags

(Not tracked)




15 years ago
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.

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

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

Comment 2

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

Comment 3

15 years ago
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.
Product: Browser → Seamonkey

Comment 4

13 years ago
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.
Last Resolved: 13 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.