Closed Bug 291443 Opened 15 years ago Closed 15 years ago
drag-select broken in drop down boxes
26.57 KB, text/html
2.00 KB, patch
|Details | Diff | Splinter Review|
1.47 KB, patch
|Details | Diff | Splinter Review|
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:
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
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
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
Always point the mouse capture at the scrolled frame.
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
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+
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.
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
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
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).
This enabled mouse capturing for mousedowns in dropdown lists. It seems to work great.
Comment on attachment 188564 [details] [diff] [review] additional fix r+sr=bzbarsky; test well!
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+
Status: REOPENED → RESOLVED
Closed: 15 years ago → 15 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.