27315 - SELECT drag-select stops working after first drag above/below

Status: RESOLVED WORKSFORME

(Core :: Layout: Form Controls, defect)

Description

[Eli Goldberg]

Checked using 2000021008 builds on Win32/Mac OS.

Steps to reproduce:
1. View a web page such as http://bugzilla.mozilla.org/enter_bug.cgi?product=
Browser, with scrolled select lists.

2. Attempt to drag select such a list (e.g. Component)

Actual results:
---> Drag selection doesn't do anything.

Expected results:
---> Behavior similar to Win32 & Mac OS widget sets --- drag selection should be 
supported.

Comment 1

[karnaze (gone)]

Reassigning to Rod.

Comment 2

[rods (gone)]

Setting to M16

Comment 3

[rods (gone)]

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

Comment 4

[Jukka Santala]

"Fix" for this (Actually, 29990 which is marked as duplicate of this...) in 
layout\html\forms\src\nsListControlFrame.cpp:MouseMove() prevents compiling on 
VC5 due to all control paths not returning a value. This is also a potential bug 
because method may get called by something that expets a return value.

Comment 5

[rods (gone)]

This now works except for auto scrolling when below or above the list.

Comment 6

[rods (gone)]

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

Comment 7

[rods (gone)]

mass-move to M16

Comment 8

[Jesse Ruderman]

Related: bug 34020 for scrolling the content area while selecting.

Comment 9

[rods (gone)]

moving bugs to M17

Comment 10

[ekrock's old account (dead)]

Revising summary per rods's comments.  Pushing out to M19 as: (1) there's a 
workaround: scroll using arrows and shift-select to select the whole group, (2) 
this only affects drag scrolling ith auto scroll when above/below list, (3) we 
have higher priorities, and (4) we could live with this for FCS if necessary.

Comment 11

[rods (gone)]

This bug has been marked "future" because at this time it has been determined 
that it is not absolutely critical for RTM (Release To Manufacturing). If the 
reporter and anyone else believe it is necessary to fix this before shipping 
Seamonkey 1.0, please describe your issue in the bug. 

Comment 12

[rods (gone)]

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

Comment 13

[Blake Ross]

erg...future...:(

rods, can you give me a general idea of what implementing this would entail 
(and where changes would have to be made)?

Comment 14

[Blake Ross]

disregard my last comment, as this isn't the same as 44454 (I thought it was 
initially), which I had more interest in fixing

Comment 15

[bsharma]

Updating QA contact.

Comment 16

[rods (gone)]

leaving P3/Future for now.

Comment 17

[rods (gone)]

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

Comment 18

[rods (gone)]

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

Comment 19

[Blake Ross]

Can someone clarify what this bug is still open for?  Upon further reading, it 
seems to be the same as bug 44454.  What Rod mentioned on 3/16 seems to be 
fixed also.

Comment 20

[rods (gone)]

I think this is left open because drab scroll doesn't work and you drag off the 
end of the list. In otherwords, it should continue to scrol the list.

Comment 21

[rods (gone)]

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

Comment 22

[Vladimir Ermakov]

QA Contact Update

Comment 23

[John Keiser (jkeiser)]

It appears that scrolling off the bottom of the list is working; but off the
top, no cigar.  Try http://bugzilla.mozilla.org/query.cgi for some examples.

Comment 24

[Jesse Ruderman]

I'm seeing something different: if I try to drag-scroll up and then drag-scroll 
down, it only works going up, unless I go down really far below the bottom of 
the select.  But if I do the opposite, it only works going down!  It's as if 
the scroll-off, selected items block Mozilla from realizing that I'm below the 
bottom (or above the top) of the listbox.

Comment 25

[John Levon]

is this still futured given comment 23 and comment 24 ? I also see this on
linux with a currentish build :(

Comment 26

[Boris Zbarsky [:bzbarsky]]

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

Comment 27

[Boris Zbarsky [:bzbarsky]]

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

Comment 28

[Matthew T (active 1999-2002)]

Reproduced in build 2002071403, Mac OS 9.2.2.

Resummarizing to minimize confusion with bug 63295. Bug 46497, bug 63072, and
bug 59459 were duplicates of bug 44454, not this bug. Some of the other
duplicates of this bug should probably be duplicates of bug 63295, not this bug.

Comment 29

[Andrei Boros]

Attachment: Drop down select and multiple select testcase

I've attached a testcase for this bug that illustrates both cases when Mozilla
shows odd behaviours, and there are more variations then those aleady described
in this bug so far.

1) in drop down select, when using the mouse to make a selection, the options
are more then the displayed ones and a scroll bar exists, dragging the mouse
down to a value not yet visible may not always work. 
I got different results at various times:
- I was able to go down to the last value (correct)
- I was not able to go down past the last displayed value when the pull down is
extended the first time
- I was able to get some steps down, but not all
- moving the mouse fast and exiting the area of the unrolled pull down list
will stop the selection scrolling towards the last value.

Similar results are encountered with the multiple select, with an added twist:
- if multiple select is partially visible in the currently displayed area of
the window, scrolling down with the mouse left click and held will select all
visible values, but will not scroll the entire window so that the bottom of the
select input field is visible.
- writing text in a textarea that is partially visible does trigger a scroll so
that the bottom of the textarea becomes visible as the cursor  goes down.
(same is valid for going up and sideways but only for input type text and
textarea)

If user wants to do a multiple selection starting from the bottom, there is no
way to select with a single mouse left click and drag upwards more then the
visible values in that select. No scroll will take place upwards.

Same is valid for drop down list.
As in the testcase: pull down the list, go down so the the last value (31) is
visible. Left click and hold mouse and move mouse upwards. It will not scroll
at all, 16 being the top most visible value it stops there.

In the multiple select, go down to 31, left click and hold, move upwards. As
about 2 pixels are visible from value 26, depending on how fast you move the
mouse, the top most selected value can be 27 or 26, but there is no wy to
select more then this.

(my screen resolution is 800x600)

Comment 30

[John Levon]

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

Comment 31

[John Levon]

The bug I just duped, is talking also about single-select scrolling
in HTML listboxes, which this bug seems to be about. Shouldn't
the "MULTIPLE" be removed from the subject ?

Hmm, actually. bug 44454 is marked as fixed but there are two
cases where things s till fail :

1) open a combo box and keep the mouse button held down. scrolling
does not work

2) open a combo box, release mouse button, select an item, and try
to scroll upwards by hold position above the t op of the listbox.
nothing happens.

Bleh. Confusion.

Comment 32

[Mats Palmgren (inactive)]

The original problem was fixed by bug 291443.
The additional problem mentioned in comment 29 regarding scrolling the
surrounding views to make the selection become visible is covered
by bug 56602.

-> WORKSFORME