Closed Bug 291443 Opened 15 years ago Closed 15 years ago

drag-select broken in drop down boxes

Categories

(Core :: Widget, defect)

x86
All
defect
Not set

Tracking

()

RESOLVED FIXED

People

(Reporter: bugs.caleb, Assigned: roc)

References

Details

(Keywords: regression)

Attachments

(3 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050421 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050421 Firefox/1.0+

If you open a drop down and then left click on one of the items and then pull
your mouse up or down to make it scroll and follow your selection it only does
this for 1 or 2 items and then just stops.

I believe that this is a regression, could be before (since drop downs were
broken before the fix anyway) or after the checkin for Bug 290921.

Reproducible: Always

Steps to Reproduce:
Attached file testcase
Keywords: regression
Confirming with build 2005-04-22-06 on Windows XP.  This may be known (I'd hope
it is, since we're nearing a milestone).
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking1.8b2?
Flags: blocking-aviary1.1?
So when, exactly, did this regress?  Note that either I don't understand the
steps, or there is no way to reproduce this bug on Linux -- I can't get a
dropdown to scroll by mousing down inside it and dragging somewhere.
(In reply to comment #3)
> So when, exactly, did this regress?  Note that either I don't understand the
> steps, or there is no way to reproduce this bug on Linux -- I can't get a
> dropdown to scroll by mousing down inside it and dragging somewhere.

Steps to reproduce were:
1. Open a drop down
2. Left click and hold on one of the items
3. Try moving the mouse up or down to make the drop down scroll

It only scrolls for 1 or 2 items and then stops.

I'm not really sure when this regressed, I just know that it works properly on
1.0.3.
> I'm not really sure when this regressed,

Any chance of testing some nightly builds from archive.mozilla.org to narrow
this down?  Your steps to reproduce aren't exactly what I see with 1.0.3 (I have
to keep moving the mouse there to get the list to scroll).

I _do_ see a behavior change between 2005-03-28-06 and 2005-03-29-06 -- in the
latter (and subsequent builds) there is no scrolling even if I move my mouse.

roc, that looks like a possible regression from bug 284664...
Assignee: jag → roc
Blocks: 284664
Shouldn't a regression be put in the "depends on" rather than the "blocks" field?

By "try moving the mouse up or down" I meant scrolling, sorry for the confusion. 

I'll test some nightly builds right now to find when this regressed.

> Shouldn't a regression be put in the "depends on" rather than the "blocks"
> field?

Depends on whether you view it as "can't fix the regression until the other bug
is fixed" or "can't consider the other bug fully fixed until the regressions are
fixed" I guess.

> By "try moving the mouse up or down" I meant scrolling

You mean with a scrollwheel?  I thought you meant dragging the mouse pointer up
or down (that's what "moving" means for a mouse).

If you mean a scrollwheel, could you please narrow down when this regressed
using the nightlies?  I don't have a scrollwheel to test with.
> You mean with a scrollwheel?  I thought you meant dragging the mouse pointer up
> or down (that's what "moving" means for a mouse).

No, not a scrollwheel.. lol I guess I confused you even more by trying to clear
it  up.. sorry just woke up :P

By _scrolling_ I meant dragging the mouse while the left mouse button was pressed.
The expected behaviour when the mouse reaches the last item in-view in the drop
down and you drag it beyond the border is to scroll the drop down with the mouse.

Results coming in a second..
Sorry for the slight delay, I accidently tested 5 builds from 2004 instead of
2005 :P

You were right, bug 284664 is the culprit.

Working in 2005-03-28-08, broken in 2005-03-29-07.
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=MozillaTinderboxAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-03-28&maxdate=2005-03-29&cvsroot=%2Fcvsroot
Attached patch fixSplinter Review
Always point the mouse capture at the scrolled frame.
Attachment #181823 - Flags: superreview?(bzbarsky)
Attachment #181823 - Flags: review?(bzbarsky)
Comment on attachment 181823 [details] [diff] [review]
fix

The old code points mouse capture at the _parent_ of the scrolled frame... was
that wrong?

If so, r+sr=bzbarsky
Attachment #181823 - Flags: superreview?(bzbarsky)
Attachment #181823 - Flags: superreview+
Attachment #181823 - Flags: review?(bzbarsky)
Attachment #181823 - Flags: review+
Yes, I believe it was wrong. Making it the scrolled frame's view means that I
can actually scroll a combobox dropdown by dragging outside it now, on Linux.
Comment on attachment 181823 [details] [diff] [review]
fix

fix regression in listboxes (and an older bug in Linux combobox dropdowns)
Attachment #181823 - Flags: approval1.8b2?
Comment on attachment 181823 [details] [diff] [review]
fix

a=chofmann
Attachment #181823 - Flags: approval1.8b2? → approval1.8b2+
checked in
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Reopening.

The patch only fixes scrolling in the listbox, but not in the combo box.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Hmm.

You mean moving the mouse doesn't cause combobox dropdowns to scroll in WIndows?
(In reply to comment #17)
> Hmm.
> 
> You mean moving the mouse doesn't cause combobox dropdowns to scroll in WIndows?

Yes, that's what I mean.

Open a combobox, left click on an item, while holding the mouse button, drag the
mouse down (beyond the borders of the combobox. It should scroll, just like the
listbox does, but it doesn't.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050426
Firefox/1.0+
Well, it's definitely working for me in Linux on trunk right now.

Did dragging outside comboboxes used to work on Windows? Or did I just break it?
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050502
Firefox/1.0+

Combo boxes are still broken, and now listbox are partially broken. 

You can "drag-select" downards, but not upwards in listboxes now.

Just try the testcase again.
Flags: blocking1.8b3?
Flags: blocking1.8b2?
Flags: blocking1.8b2-
recheck once 290428 lands
Depends on: 290428
(In reply to comment #21)
> recheck once 290428 lands

the patch in bug 290428 has landed, and this bug is still an issue (with the
combo boxes, not the list boxes)
Component: XP Toolkit/Widgets → Widget: Photon
Is this really a bug in Widget:Photon?
Help me, ere!

I have a feeling there's a single underlying bug in Windows widget mouse event
handling that is causing a variety of issues...
Component: Widget: Photon → Widget: Win32
I'll try..
Umm.. how does a combobox actually work? It seems dragging works fine if the
drag is initiated from the main widget (parent widget in a combobox?) of the
combobox. Then the mouse move events are directed to the main widget and the
listbox is scrolled. If the drag is started from the listbox, it's not scrolled.
It seems nsWindow impl on Win32 works right as I'd expect, but why would the
listbox only scroll when the messages are passed to its parent?
I'm not really sure if clicking in the listbox after it's dropped down should
initiate mouse capture.
Hmm.

If you click and hold on the combo box and then move the mouse up/down the combo
box scrolls with the selection.

But if you click the combo box, and then try to left click, hold and move the
mouse up/down, it does not scroll with the selection anymore.
Component: Widget: Win32 → Build Config
Not build config.. And yes, that's what I said in comment #26.
Component: Build Config → Widget: Win32
I've been trying to compare win32 and gtk2 behavior, but I'm having trouble
getting a linux build running. 
find me on IRC and we can work together with my GTK2 build
Flags: blocking1.8b4+
Flags: blocking1.8b3?
Flags: blocking1.8b3-
Flags: blocking-aviary1.1?
Flags: blocking-aviary1.1+
I have the linux build running now, will do some testing..
Heh, I see the same problem in my gtk2 build on Fedora Core 4 (running in
VMWare). This leads me to suspect the problem isn't in win32 support code..
OS -> All according to my tests. Falls outside my scope.
Component: Widget: Win32 → Widget
OS: Windows XP → All
Sorry Ere.

How do other Windows apps work? Do they capture the mouse when the user
mouse-downs in the dropped down list?
NP. Yes, at least they should. 

Some programs autoscroll better than others. For example IE and some others, I
think, only scroll the list when the mouse moves but I believe the native combo
box has a nice autoscroll with speed depending on how far the cursor is from the
box. Mozilla seems to work (in the case this works) like IE but has the nice
distance related scrolling speed.
THen I guess we need to implement that.
Agreed. Besides, it used to work for example in 1.7.8 and FF 1.0.4 (albeit not
always perfectly, it sometimes hesitates to scroll to the last or first line).
Attached patch additional fixSplinter Review
This enabled mouse capturing for mousedowns in dropdown lists. It seems to work
great.
Attachment #188564 - Flags: superreview?(bzbarsky)
Attachment #188564 - Flags: review?(bzbarsky)
Comment on attachment 188564 [details] [diff] [review]
additional fix

r+sr=bzbarsky; test well!
Attachment #188564 - Flags: superreview?(bzbarsky)
Attachment #188564 - Flags: superreview+
Attachment #188564 - Flags: review?(bzbarsky)
Attachment #188564 - Flags: review+
Comment on attachment 188564 [details] [diff] [review]
additional fix

Caleb tested this and verified it works on Windows. I tested it and verified
that onchange still fires correctly.

This fixes a UI regression.
Attachment #188564 - Flags: approval1.8b3?
Attachment #188564 - Flags: approval1.8b3? → approval1.8b3+
checked in
Status: REOPENED → RESOLVED
Closed: 15 years ago15 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.