44454 - [FIX]Can't drag-scroll/-select in single-select HTML listboxes

Status: VERIFIED FIXED

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

Description

[Blake Ross]

I hate filing dups, but I just want to make sure this is out there.  One 
glaring inconsistency between native win32 and gfx listboxes is that you can't 
select an item in a gfx listbox and drag up or down to select other items and 
scroll the contents of the listbox.  The same holds true for trees.

Again, sorry if this has already been filed (I have a feeling it has, I recall 
seeing it but am unable to find it now) -- just making sure it gets noticed.

Comment 1

[Mike Pinkerton (not reading bugmail)]

can you give an example of where one of these gfx listboxes lives in the chrome?

Comment 2

[Blake Ross]

sorry, I reported this wrong.  I meant HTML listboxes don't let you drag scroll 
& select, and gfx trees don't let you either.  I'll send this to rods and split 
off the tree issue into a separate xpt bug....OK?

Comment 3

[rods (gone)]

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

Comment 4

[Blake Ross]

vrfy

Comment 5

[Blake Ross]

Nevermind, this isn't a dup.

I'm talking about listboxes where you can only select one item...you should be 
able to scroll the listbox via mousing down on on item and moving the cursor up 
or down.  The difference is that in single-select listboxes, only one item 
should be selected at a time

Comment 6

[rods (gone)]

I am confused, in a select with size > 1, if I select an item via the mouse, I 
can then arrow up or down and it scrolls and selects. Could you please describe 
again what is wrong?

Comment 7

[Blake Ross]

Sorry for not being more clear.  In a select with a couple of items, when you 
can select only one item at a time, you should be able to mousedown on on item, 
and then move the cursor upwards or downwards to select the next subsequent 
item, scrolling the list as necessary.  In the current implementation, if you 
mousedown on an item and move the cursor up or down without letting go of the 
mousebutton, we do nothing -- whatever item was selected remains selected.

I'm not sure how other OS's behave, but this is standard on win32 -- try it 
out.  It's such a simple action that it's hard to describe (if you need more 
clarification, just ask)

A friend and I were looking into the code and didn't think this would be too 
hard to do at all.  It would be *very* similar to the drag select behavior of 
multiselect listboxes, except that in this case, only one item could be 
selected at a time.

Comment 8

[rods (gone)]

I get it now! I'll take a quick look at this, and you are right, it shouldn't be 
too hard.

Comment 9

[rods (gone)]

Easy fix, I have it in my tree

Comment 10

[Blake Ross]

I'm kind of interested in seeing this get in a little sooner than beta3...would 
that be possible?  Or would you rather I check it in under the contributor 
rules (you review, and I'll get approval from waterson or brendan)?

Comment 11

[rods (gone)]

Nominating for nsbeta2, low risk fix

Comment 12

[Jay Patel [:jay]]

Putting on [nsbeta2-] radar. Not critical to beta2. 

Comment 13

[Blake Ross]

argh...alright.

nominating for beta3, but if you don't mind Rod I'll check this in when I get 
back (I'll just get approval from brendan/waterson)

Comment 14

[Peter Trudelle]

Blake- unless you've recently been hired by NS/AOL, you don't need nsbeta+ 
approval to checkin your fixes, only proper review and module owner approval.

Comment 15

[Kevin McCluskey (gone)]

Marking nsbeta3+

Comment 16

[rods (gone)]

fixed

Comment 17

[Blake Ross]

awesome.  works perfectly in 80308.  Thanks a lot, Rod.

Comment 18

[Daniel Veditz [:dveditz]]

Adding keyword to bugs which already show a nsbeta2 triage value in the status 
whiteboard so the queries don't get screwed up.