Closed Bug 40983 Opened 24 years ago Closed 23 years ago

[LST]multiselect listbox behaviors

Categories

(Core :: Layout: Form Controls, defect, P5)

x86
Windows 2000
defect

Tracking

()

VERIFIED FIXED
Future

People

(Reporter: timeless, Assigned: john)

References

()

Details

(Keywords: access, testcase)

Attachments

(2 files, 1 obsolete file)

20000528

standard protocol for win32: ctrl-click selected deselects, ctrl-click 
unselected selects

[Well that makes enough sense. What doesn't make sense is that it takes a 
ctrl-click to invert a click.]-[Drag select 3 things, then click one of them, 
the result (which is reasonable) is that only it is selected]

Hrm. It doesn't support drag-deselect either.
drag deselect?

on nn4 drag deselect will result in 0 selected
in moz you are left with the top one selected
1) and you can only drag deselect bottom up
;-)

2) drag deselection is very buggy
go to query
ctrl click new, reopened, verified, closed
then ctrl drag from closed to unconfirmed
in moz that leaves un and new selected
in nc4.73/ie5.5 they're all unselected
I really don't understand what the bug is here. Drag select seems to work just 
like Nav 4.x, please provide exactly the steps I need to do to reproduce what 
you are seeing.
Target Milestone: --- → M17
Setting to future until I understand what is wrong
Status: NEW → ASSIGNED
Target Milestone: M17 → Future
Updating QA contact.
QA Contact: ckritzer → bsharma
Summary: multiselect listbox behaviors → [LST]multiselect listbox behaviors
I asked for this bug to be clarified some time ago, I am marking this invalid, 
please reopen if necessary and provide an exact description of what needs to be 
fixed. Thanks
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → INVALID
i've spoken with timeless, and he walked me through some steps. the problem here 
is that control+drag in a listbox doesn't behave as it should in 
communicator4.x/IE.

1. go to a page containing a listbox, eg the Status listbox in 
http://bugzilla.mozilla.org/query.cgi.
2. using control+click, select the 1st, 3rd and 7th [last] items in the Status 
list.
3. now, control+drag the mouse from the 1st list item down to the last one.

result: [as seen in 4.x/IE] all the items within the range you have 
control+dragged over should now become deselected. in this testcase, the 1st 
through 7th items are deselected.

actual: the 1st item is deselected, but the rest of the range [from the 2nd to 
7th item] are selected.

tested on winNT using 2000.12.13.08 comm verif bits. timeless, let me know if 
i'm missing anything else!
Status: RESOLVED → REOPENED
Keywords: 4xp, access, testcase
Resolution: INVALID → ---
I see what it does now, this probably won't be fixed for a very long time 
however. There are many more higher priority bugs ahead of this.
Status: REOPENED → ASSIGNED
Priority: P3 → P5
QA Contact Update
QA Contact: bsharma → vladimire
This will be a lot easier to fix after bug 34297 lands ... not too big a deal. 
As an aside, CTRL+SHIFT+keyboard movement should do the same thing as CTRL+drag.

Adding dependency so I don't forget.
Depends on: 34297
Attached patch Fix for selection (obsolete) — Splinter Review
- Makes CTRL+drag work like CTRL+clicking on subsequent elements
- Leaves CTRL+SHIFT = SHIFT
- Opens up keyboard actions for the CTRL key (now CTRL+downworks)

Open question: should space select the current option (and CTRL+space toggle)?
So talking with timeless and mpt, general changes here:

1. CTRL+first-letter should do nothing in anticipation of ctrl+C copying
selected item / items
2. space should select, CTRL+space should toggle (well, this is still in dispute).
3. CTRL+up/down/left/right/home/end should give the element "focus" without
selecting it (this would be invisible but we could do it by setting
startIndex/endIndex)

I'll produce another patch soon.  Taking bug.
Assignee: rods → jkeiser
Status: ASSIGNED → NEW
Blocks: 109318
I've always found the ctrl-click selection in list boxes (e.g. the Status in the
bugzilla query page) to be very flaky -- sometimes it adds to the selection,
sometimes it acts like an unshifted click, and it usually takes me three or four
tries to get the selection I want (as opposed to NS4, where unshifted click
always toggled without deselecting the other items).  I wonder if I'm the only
one seeing that (on linux)? I didn't know I could drag in these widgets, so
maybe I'll start using that instead.
Attached patch New PatchSplinter Review
This one contains the previous enhancements plus:
- SPACE selects, SHIFT+SPACE mimicks shift+click, CTRL+SPACE mimicks ctrl+click

- CTRL+arrow/home/end/etc. does not select anything, it just moves to that
space so you can select with SPACE
- CTRL+first-letter doesn't do anything

It's kinda spooky right now because you don't really know what option you're
over for CTRL+arrow (there's no outlining), but I suggest we do this and file
that as a separate bug.  At least we scroll when you move in this way.
Attachment #57884 - Attachment is obsolete: true
Comment on attachment 59473 [details] [diff] [review]
New Patch

r=mpt for UI (from IRC)
The "show selection as dotted line" bug is bug 64165.
I am having a real hard time figuring out what this patch really does.

ctrl home,end,arrow does nothing, not even moves the selection

(Note: ctrl click drag just toggles everything)

That's strange, I don't think I was seeing that.  I'll check it this evening,
thanks.  CTRL+click drag is supposed to toggle everything, as noted in previous
patch ...  I can pretty easily make it set all subsequent elements same as the
current element, but that's sort of inconsistent with what it seems like CTRL does.
Status: NEW → ASSIGNED
What This Patch Does (condensing previous comments).

With the patch:
- normal keyboard selection stays the same
- CTRL+drag works like CTRL+clicking on subsequent elements
- CTRL+SHIFT = SHIFT for all relevant actions (this is how it was before)
- SPACE selects, SHIFT+SPACE mimicks shift+click, CTRL+SPACE mimicks ctrl+click
- CTRL+arrow/home/end/etc. does not select anything, it just moves to that
option so you can select with SPACE
- CTRL+first-letter doesn't do anything

As noted previously, until we have outlines the arrows keys will not look like
they are doing anything (unless you scroll off the end of the box).  This is
spooky, but a separate bug.  That's probably what you were seeing.
The spooky bug is bug 64076, "Show dotted border around focused item in 
listboxes/trees/outliners".
Just keepin' up with the Joneses.  Same patch.
r=rods
Comment on attachment 61695 [details] [diff] [review]
Update Against Current CVS

look good to me. sr=attinasi
Attachment #61695 - Flags: superreview+
Blocks: 112281
John Keiser, is this going to land any time soon? 
This is the same status as another--I left for vacation and now all Internet
access is gone until the damn cable guys come out next week.  I will find other
options for checkin (like work), but if anyone has time to check it in, please
do.  I'll be available on email.  This fixes your CTRL+click problem, asa, BTW.
 (I seems like it does anyway.)
checked in.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago23 years ago
Resolution: --- → FIXED
This did not fix bug 112281 as was suggested there. If someone wants to take a
look at it now that'd be great.
No longer blocks: 112281
QA Contact: vladimire → tpreston
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020901
based on steps in comment 5
vrfy fixed

yes i originally hoped that the range extension stuff (ctrl-shift) would work
too, but i decided it was hard enough to explain simple inversion, so we'll
track that in bug 112281.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: