Closed Bug 33732 Opened 25 years ago Closed 20 years ago

[MW] mouse wheel scrolls listbox, even when cursor is outside listbox

Categories

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

Product:
Core
Component:
Layout: Form Controls
Platform:
x86
Windows NT
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Future

People

(Reporter: ashted, Assigned: frank.schoenheit)

References

(
URL
)

Details

(Keywords: helpwanted, relnote, Whiteboard: MozBugFood)

Attachments

(1 file, 4 obsolete files)

no more tabs ...
2.72 KB, patch
rods
: review+
dbaron
: superreview+
Details | Diff | Splinter Review
From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; N; WinNT4.0; en-US; m14) BuildID: 2000032808 Using the Genius Netmouse and non-gfx-scrollbars (so that the netmouse wheel will work ;-), if the pointer is on the form, but not on a form element, the mousewheel will scroll a form element. Reproducible: Always Steps to Reproduce: 1. Got to the listed URL 2. Place the pointer in the whitespace after "Run this query" 3. Use the mousewheel and watch the "Target Milestone" picklist scroll Expected Results: The page should scroll instead of the form element.
Since I can't login, I need a reduced test case. I get get it to crash.
I'm not sure we really have much control over how mousewheel events are handled for native scrollbars.
In your opinion, is this bug then dependent on bug 22794? Alternatively, is it possible to see these symptoms with the gfx scrollbars on? I don't have a "normal" mousewheel available to test that.
mass-move to M16
Target Milestone: --- → M16
Moving out by executive order.
Target Milestone: M16 → M17
nominating for nsbeta2 based on: - visibility - feature broken
Keywords: nsbeta2
Can PDT get a retest here please. Also do not think that we are supporting navtive scrollbars. Are we?
Whiteboard: [NEED INFO]
Problem still exists. Please see comments on bug 33733 regarding native scrollbars.
Putting on [nsbeta2+][6/01] radar. This work must be done by 06/01 or we may pull this for PR2. Need a test against the latest build please.
Whiteboard: [NEED INFO] → [nsbeta2+][6/01]
The problem is the mousewheel events are going to the part of the window that is not visible and is suppose to be completely clipped out by the scrolling window.
Status: NEW → ASSIGNED
Priority: P3 → P1
Target Milestone: M17 → M16
Still happens on 2000-05-16-09 Windows Commercial build.
This was NOT working in a recent build, but with today's pull and build it now works as it should. I think it may have been an EventStateManager bug. marking as works for me.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → WORKSFORME
I think this just got fixed. Check the commercial build tomorrow.
Hmmnn...for some reason my comments didn't take yesterday.. This still happens on WinNT 2000-0517/18-09-M16 Commercial builds.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Are you seeing this happen on just the commercial builds right now?
This works for me, can someone verify this?
Status: REOPENED → ASSIGNED
Summary: Mousewheel scrolling scrolls last form element → [WFM]Mousewheel scrolling scrolls last form element
Problem still exists on 2000052508. Once again, this is using the native scrollbars. I can't use the gfx scrollbars because I have a Genius netmouse. I still think that this should be dependant on 22794 or 33733.
Due to slip in schedule, moving this bug from [6/01] to [Will be minus on 6/15] for fix deadline.
Whiteboard: [nsbeta2+][6/01] → [nsbeta2+][Will be minus on 6/15]
What I am seeing is, it only scrolls the listbox if the listbox already has focus. If you load the page and don't click on anything then it does scroll anything but the page itself. Is that what you are seeing?
Negative. Using build 2000060120, WinNT, no gfx scrollbars, if I load up, say, the query page (http://bugzilla.mozilla.org/query.cgi) and, without clicking anywhere, move my pointer to the middle of the first Email selection box, say on the text "(Will match any of the selected field)", the Genius Netmouse mousewheel action results in movement in the OpSys box.
Adding dependency to 22794
Depends on: 22794
I guess I should have said that this is only a problem with the Genius netmouse
I think I know what's going on here. The mouse driver is finding the closest native scrollbar to the mouse pointer and scrolling it. Mozilla itself is not seeing the mousewheel events at all. Rod, do you think this is fixable?
Not, off the top of my head. we may have to release note it.
Could someone explain to the uninitiated why this is? Mozilla appears to be the only application which does this. In Opera, for instance, the mousewheel scrolls only what the pointer is on. Is this a focus problem, perhaps?
I've got an idea on this... I will try some things out today and update status.
I can't figure out a sane way to fix this while we still have native scrollbars on selects. Marking dependency (and removing 22794 dep. since rod said it was probably incorrect, via email).
Depends on: 18895
No longer depends on: 22794
But solving it by moving to gfx scrollbars doesn't fix the problem until bug 22794 is fixed (thus the dependency) becuase the problem, as reported has to do with the Genius Netmouse and that doesn't work with gfx scrollbars until 22794 is fixed. I'm still curious as to what is different about Mozilla that it can't make this work right with native scrollbars.
*** Bug 31613 has been marked as a duplicate of this bug. ***
I still haven't been able to reproduce this problem.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → WONTFIX
Rod - It may depend on your particular mouse and driver. What mouse are you using, does it have any sort of helper app running in the system tray, and what OS/version are you running?
*** Bug 42595 has been marked as a duplicate of this bug. ***
This needs to be reopened. It is still happening (could be mouse driver dependent), and makes mousewheel scrolling pages with form controls on win32 very difficult. I don't see a good way to fix this without gfx scrollbars on listboxes, either.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Summary: [WFM]Mousewheel scrolling scrolls last form element → [WFM]Mousewheel scrolling scrolls a form element
*** Bug 44533 has been marked as a duplicate of this bug. ***
I think this IS driver depenedent, I am not sure what to do with it, I can't reproduce it.
Status: REOPENED → ASSIGNED
Target Milestone: M16 → M17
Rod - I can tell you that it happens on my system, WinNT 4.0 with a Logitech Firstmouse+. If you have some ideas on how to fix it, I'd be happy to test.
I don't have any idea how to fix it without being able to reproduce the problem. Not to mention that it is probably a driver problem so I doubt there will be some generic fix.
Setting to nsbeta2-, we can ship nsbeta2 without this
Whiteboard: [nsbeta2+][Will be minus on 6/15] → [nsbeta2-][Will be minus on 6/15]
I have encountered that problem with Build 080104 now, too. Fact: mousewheel is not scrolling the page, no matter which element is active. Where: http://bugzilla.mozilla.org/show_bug.cgi?id=45390 What: as soon as there are more CC-eMails in the Cc: Select-Box (scroller enabled) the mouse-wheel is scrolling only this select field anymore. This is working fine under all other browsers (except Gecko). It is definitly no driver problem of user side.
A bug being driver-dependent is not necessarily the same as a driver problem. In this case, it's up to the mouse driver if it wants to try to scroll a native scrollbar. This problem is not going to go away until we can completely remove native scrollbars from the product.
*** Bug 47713 has been marked as a duplicate of this bug. ***
This problem occurs with M17/Win32, using a Logitech Optical Mouse and Logitech MouseWare drivers 9.00 / ControlCenter 9.00.99 using non-native scrollbars (the "Classic Skin"). Scrollable elements on the page (for example, http://bugzilla.mozilla.org/query.cgi ) receive wheel events regardless of focus or pointer position.
*** Bug 48380 has been marked as a duplicate of this bug. ***
*** Bug 48391 has been marked as a duplicate of this bug. ***
modifying summary since, per the dupes, this clearly doesn't work anymore. Also, doesn't this just happen with listboxes (as opposed to 'some form elements' ?) I'd like to nominate for beta3 since this makes scrolling pages with listboxes via the mousewheel nearly impossible (if not very frustrating). But I suspect that's impossible, since this can only get fixed when bug 18895 is fixed, and that's been futured...(damn!)
Summary: [WFM]Mousewheel scrolling scrolls a form element → Mousewheel scrolling scrolls listbox, not page
Whiteboard: [nsbeta2-][Will be minus on 6/15] → [nsbeta2-]
*** Bug 48841 has been marked as a duplicate of this bug. ***
clear nsbeta2 info marking as future unless someone wants to renominate for nsbeta3
Keywords: nsbeta2
Whiteboard: [nsbeta2-]
Target Milestone: M17 → Future
Well.... I'd like to see this fixed (it makes mousewheel scrolling on win32 virtually unuseable on pages with listboxes), but if you are sure we aren't going to get gfx scrollbars in listboxes done before RTM, I guess this has to be futured.
*** Bug 53548 has been marked as a duplicate of this bug. ***
Updating QA contact.
QA Contact: ckritzer → vladimire
Summary: Mousewheel scrolling scrolls listbox, not page → [MW]Mousewheel scrolling scrolls listbox, not page
*** Bug 60580 has been marked as a duplicate of this bug. ***
*** Bug 60571 has been marked as a duplicate of this bug. ***
This is obviously an important issue (see the number of duplicates coming in). If it is dependant on some other bug, then that other bug should have its target/priority moved way up. I too am getting this behaviour with WinNT4 and Logitech mousewheel ver. 9.00 and it is very annoying. I've also noticed that the wheel doesn't work at all if the webpage is very long (like this bug) - maybe the page IS scrolling in micrometers ;-) It seems that the wheel should scroll "that" area where the mouse is currently located (hovering) and not which part of the webpage currently has focus.
Suggestion: if "rods" can't reproduce the bug (and therefore can't fix it), i would suggest that it be assigned to someone else.
Hi, I'm on NT4 running 0.7 with an IBM ScrollPoint mouse (not a laptop). This mouse uses Logitech MouseWare v8.21 and runs em_exec in the background. I'm having the usual problem with long listboxes scrolling instead of the page, but my mouse control panel has a checkbox to "Use Office 97 Compatible Scroll Only." When I check this box, it behaves normally. The whole page scrolls, not the form elements. Hope this helps.
I'm running mouseware 9.24 in windows 98se. Here are some things I noticed: with "office compatable scrolling" enabled, all applications scroll the last thing clicked on. with it disabled, all applications scroll the thing under the cursor at the time. Mozilla, however seems to scroll something at random. I whipped out spy++ and started scrolling in ns4.75, it appears as though WM_VSCROLL messages are sent to the window under the cursor in "non compatible" mode. when office compatible mode is turned on, it sends a WM_MOUSEWHEEL message to the window with focus. Hope this helps...
*** Bug 66671 has been marked as a duplicate of this bug. ***
Keywords: mostfreq
Keywords: mozilla0.9
With mousewheels now widespread and used by nearly everyone, shouldn't this bug receive more attention than it has so far? Can you at least set a milestone for this? I suggest 0.9 or 1.0 latest.
I think this bug needs to be fixed, quite annoying on pages with listboxes (such as BugZilla =) Can we nominate for 0.9? This is something that should be fixed before a beta branch, as many end users will consider mousewheel scrolling a basic functionality.
taking PLairo@cs.com's advice and nominating for mozilla0.9. marking MozBugFood plairo: please stop making useless and annoying suggestions. This is your bug now please fix it asap, or stop acting as if you were a netscape manager.
Assignee: rods → PLairo
Status: ASSIGNED → NEW
Whiteboard: MozBugFood
Timeless, please refrain from silly (newsgroup-like) games here. I am not a programmer (unfortunately) and can therefore not fix this bug (unfortunately). My comments were all productive (I checked). If you feel stressed by my suggesting a milestone of 0.9 or 1.0, then I would recommend a vacation or a stress management seminar. I'll stop posting here, if you will too ;)
Keywords: nsCatFood
Keywords: helpwanted
*** Bug 76411 has been marked as a duplicate of this bug. ***
the whole thing works for me! i have mozilla 20010506 and scrolling works fine with win2k service pack 1
oh sorry, i see what you mean now...
*** Bug 79285 has been marked as a duplicate of this bug. ***
Had this bug. I'm using Dual Wheel Mouse V5.41. Switching to MS-Intelli Mouse compatibility mode fixed the problem.
Confirming previous: I use a logitech mouseman wheel mouse on USB. Using Windows ME on build 2001050515 (.9) If I turn on: "Use MS office compatible scroll only" It works perfectly
Ted, does this work for you, too?
Is this an issue with other OS's? If it is then this is only a partial solution. I haven't seen anyone mention Linux or Mac Can someone please test this on Linux and Mac
I have a cordless Logitech using version 9.28 of the drivers. Tried checking the box for "MS Office Compatible scroll only". This enables me to scroll the entire page in Bugzilla, but now I can't scroll listboxes without giving them focus first. For comparison, this is what happens in a bug report in Bugzilla: With MS office scroll enabled: - Mozilla scrolls the entire page. To scroll a listbox I have to mark one of the options in the list. - IE has the same behaviour. With MS office scroll disabled: - Mozilla scrolls the cc-list no matter what I do. - IE scrolls the entire page. If I mouse over one of the listboxes it scrolls instead. Moving away from the listbox it scrolls the page again. The latter behaviour is what happens with all other applications and is why I use a Logitech wheel mouse. Setting it to Office compatible may enable me to scroll the entire page, but it is not an acceptable solution as it breaks a core function in the mouse driver. This is WinMe, 2001060104.
I again agree with previous report, by Lasse Marøen. I'm using logitech mouse driver 9.1 I don't really see this as an ESSENTIAL part of the mouse's functionality. But we shouldn't be aiming for half solutions either. Long term: we should aim to capture full functionality. Short term: we should see if we can enable this feature automatically within mozilla. It's not permanent, or the best, but I don't think there's anyone that'll say that its not better than what we had before.
*** Bug 84306 has been marked as a duplicate of this bug. ***
Using Logitech Mouse v9.24 on NT4.SP6a, mousewheel only scrolls the listbox. If I change the Logitech driver to use "MS Office Compatible" mode, Mozilla will scroll pages correctly but many of my other s/w applications no longer scroll. So, I don't consider the change in driver mode a legitimate fix.
timeless, let's please put this bug somewhere where it might get fixed.
Assignee: PLairo → rods
*** Bug 85096 has been marked as a duplicate of this bug. ***
Mass move of form submission bugs, Eric, I am sorry I don't have more time to look at these closer.
Assignee: rods → pollmann
Oops, back to me
Assignee: pollmann → rods
I don't know if it helps or not, but I can scroll the main page *if* the mouse pointer is hovering anywhere over the main scrollbar while the main body of the page has focus.
*** Bug 88751 has been marked as a duplicate of this bug. ***
This bug applies to Logitech mice (at least, my Logitech Mouse running with Mouse Driver v9.00 under Windows 2000 Server) as well under Mozilla 0.9.1 and 0.9.2. Some of my observations: 1) If there is a listbox anywhere on the page, the mousewheel will scroll the listbox rather than the page, even if the listbox does not have input focus. Correct behavior would be to scroll the object (or control) that currently has input focus (or the parent object if that object is not scrollable). 2) If the mouse cursor is placed over any horizontal scrollbar, then using the mousewheel will scroll the object that has input focus. Interestingly enough, it does this even if the cursor is over the horizontal scrollbar of a different object. For instance, if, on this comments form I click on the cc: listbox to give it input focus, then place the mousecursor over the horizontal scrollbar for this additional comments box and spin the mousewheel, the listbox is scrolled rather than this additional comments box. An exception to this rule, is that placing the mouse cursor over the horizontal scrollbar for a listbox always seems to scroll the listbox, regardless of which object has input focus. Perhaps some programmer has a fetish for scrolling listboxes. 3) After scrolling to the bottom / top of a list in a list box, if a user continues scrolling past the the bottom / top of a list, eventually a few scroll up / scroll down messages will be sent to the parent frame. As far as I can tell, there is no specific ratio of mousewheel events to messages sent to the parent frame; it appears to be more or less random. Very wierd. I hope this helps.
I have logitech mouse driver 9.24. I whipped out spy++ and this is what I saw: first off, there are 2 "MozillaWindowClass" windows, the first contains the actual page. it's parent contains it, plus the scrollbar. I'll call the first the "page window" the second the "scrollbar window". All tests were done on this page. When you wheelie over the scrollbar window, it always sends WM_MOUSEWHEEL to the scrollbar window. When you wheelie over the page window, it sends WM_VSCROLL to the scrollbar on the CC listbox; no matter what has focus on the page or where the mouse is. This leads me to believe the mouse driver does something like this: on mouse wheel { if (has_scrollbar(active_window)){ SendMessage(active_window, WM_VSCROLL); }else{ foundchild=0; foreach(children(active_window) as child){ if (has_scrollbar(child)){ SendMessage(child, WM_VSCROLL); foundchild=1; break; } } if (!foundchild){ SendMessage(active_window, WM_MOUSEWHEEL); } } } Unfortunately, I don't think we can do anything about it until someone decides to implement graphic scrollbars on listboxes.
arg, there are too many of these bugs. brian: thanks for the analysis, can you please test ie? there was a comment in another bug (it and this are dupes, someone should squish one) that said changing the mozilla window class to match ie's fixed the problem for some drivers. If you can build mozilla and make that change (and test), that'd be great. Also is there documentation for these drivers? some of them have config files which allow manual overrides (others rely on the registry).. filemon/regmon would you to kind of find out if the drivers indeed do this. Spy++ should get you the ie window class, but i'll try to dig it up asap.
*** Bug 88605 has been marked as a duplicate of this bug. ***
*** Bug 83028 has been marked as a duplicate of this bug. ***
It would be best if one didn't have to first click on the "area" that one wants to scroll. IOW, whatever is *under the curser* is what should scroll (regardless of where the focus is). Hardware: M$ IntelliMouse Optical, version 3.20.
plairo: that's the subject of a different bug, please don't confuse bugs, especially these.
*** Bug 93201 has been marked as a duplicate of this bug. ***
Is this bug really only showing up on NT and/or W2K? Also, if we want this to get fixed, we should all add votes for the blocking bug 18895 ...
Should be All/All
Component: Form Submission → HTML Form Controls
I have this problem with WinME and Sony VAIO laptop touchpad.
Status: NEW → ASSIGNED
Confirmation of this bug: Logitech mouse, mouseware driver 8.01, winnt4-sp6a, mozilla build ID 2001101117 Bug happens when "use Office 97 ble Scroll Only" is unchecked. Bug disappeared when this option is checked.
Another confirmation of this bug: Windows 98 (1st ed.), Logitech mouse, Logitech Mouse Driver Version 9.41.2 (and every previous version of the driver I've used; I've lost track of them). It occurs in every Mozilla build. Checking "Use MS Office Compatible Scroll Only" in the "Buttons" Section of the Mouse Control Panel solves the problem for me, too. No behaviour like this in IE.
*** Bug 110196 has been marked as a duplicate of this bug. ***
*** Bug 113673 has been marked as a duplicate of this bug. ***
Same for me too, when I apply the "Use only MS Office compatible scrolling" option in MouseWare 9.10, the problem is gone, and the wheel works as expected.
Same for me -- using build 201120603 and Logitech optical wheel mouse. Note that it's even happening here at the Bugzilla site on the bug form: moving the wheel scrolls the CC field, even though I've never clicked in that field.
Nominating for next release. This bug affects all users who use a mouse with a scroll wheel and has 26 votes already.
Keywords: nsbeta1
See also bug 113717, which is the Mac equivalent of this bug.
Blocks: 113717
*** Bug 114873 has been marked as a duplicate of this bug. ***
No, it does not affect all users who use a scroll wheel. It affects users on Windows with certain OS/driver combinations. But for what it's worth, this will be fixed by XBL form control -- see bug 112713.
*** Bug 117111 has been marked as a duplicate of this bug. ***
*** Bug 117380 has been marked as a duplicate of this bug. ***
The recently added dupe occurred on win98. Please update the "OS" of this bug to "All". -> Text from duped bug: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.7+) Gecko/20011228 I'm using an M$ Intellimouse Optical, driver ver, ??? (how to tell?) "Mousewheel doesn't scroll page if selection is inside a multiline textbox." Reproduce: - create a new bug - enter info (incl some multiline text in "description") - leave selection in description (click there once) - move mouse anywhere and scroll mousewheel Expected Behaviour: -> Page scrolls. Actually, WHATEVER is under the mouse should scroll. The user should NOT have to click anywhere to scroll. You just *point* and scroll (NOT point, CLICK and scroll => 33% more steps involvd). Inadequate workaround: click outside multiline textbox, then scroll = annoying. PS. Could the reporter please add the keyword "mozilla0.9.8"? (This bug is almost 2 years old and highly agravating to the many mousewheel users).
plairo: this bug is a windows bug. until someone files a dupe from linux or macos it's going to keep some flavor of windows, there's no point in changing it to match the flavor of a recent duplicate. that's a bugzilla arch issue which we may or may not fix.
Me thinks somebody needs to add a "Windows", "*NIX", and "MacOS" field in the OS catagory, but I guess that's for another "bug".
nominating for 0.9.8, this bug renders the wheel all but useless on pages w/ listboxes.
Keywords: mozilla0.9.8
*** Bug 120624 has been marked as a duplicate of this bug. ***
Is this bug now dependent on bug 57209 (implement XBL controls) instead of bug 18895? Please don't let this slide until after 1.0!
For people using a Logitech mouse on Windows, grab the latest MouseWare (9.42.1, released on Jan 16 2002), it fixes the problem for those mouses. Tested on fileflash.com and some bugzilla.mozilla.org (the current one, the one for submitting new bugs ...), where the mousewheel did not work previously.
I've installed this latest Logitech driver on NT and I still have the problem when using 0.9.7. The Logitech drivers have always 'worked' if you enabled the "MS Office compatible" option. Maybe the new driver defaults to this setting. With this enabled, the only way to scroll a listbox is to click on an entry in the list, i.e., you can't scroll it by simply moving the mouse over it. There's also a new sub-option, "Scroll Active Window only", but it doesn't seem to change the behaviour.
Same on Win98. Installed new driver, no changes.
Despite Sébastien Delahaye's suggestion to install the 9.42.1 mouseware drivers I still face this problem. I can only scroll when the mouse pointer hovers the scroll bar and the listbox doesn't have the focus. NT4SP2 mozilla 2001122106
MacOS X Confirmation: I tested this bug with 2001122106 for Mac OS X and it works fine. My Windows XP machine still exhibits the problem.
Changed dependency to bug 112713.
Depends on: 112713
No longer depends on: 18895
Reassigning to bryner since this should be fixed when he lands his changes for 112713
Assignee: rods → bryner
Status: ASSIGNED → NEW
*** Bug 123036 has been marked as a duplicate of this bug. ***
*** Bug 122105 has been marked as a duplicate of this bug. ***
I use to have this bug but since I discover that it was due to "flywheel" (mouse wheel enhancer), it works fine for me ! I've put in the list of "applications not handled by flywheel" to do it ! So guys, verify that any software like flywheel is not running... (it's a workaround, though)
nsbeta1- per ADT triage team
Keywords: nsbeta1 → nsbeta1-
This is still a problem. My test case: - WinNT 4.SP6a - Mozilla 0.9.9 - Logitech v9.4.2, without "Use MS Office compatible only" - no matter where I click, the scroll-roller only affects the 1st scrollable table, eg. the "CC:" field on bugzilla bugs. If I enable the "Office-compatible only" feature, it "works" but scrolling is dependent on where I last clicked rather than simply the current hover-location. (FYI - It works correctly in Internet Explorer with either Logitech setting.)
The mouse gets caught on a list box when scrolling the page when not even hovering the listbox as you scroll. With Windows XP, all patches applied to this date, MS mouse driver 4.01 and Microsoft wheel mouse. Mozilla 0.9.9. Steps to reproduce: 1. Go to Bug 103452 on bugzilla, and scroll. The page stops scrolling at the very top, as soon as you reach the CC: listbox (mouse in the center of page, not hovering listbox) In this bug page, even though it has a CC: listbox with a scroll bar, it doesn't happen. While entering this text, to scroll the page it needs to be given focus (clicked). Otherwise the scrolling remains within the form's text-area. As a comparison, the behaviour in IE6 is to scroll to the bottom of the text-area and, without pause once reachet, continue scrolling the page. In list boxes, it does what mozilla does (i.e. scroll within the list box only and stop if the bottom of the listbox reached, without moving on to scroll the rest of the page)
I think we have enough test cases. Anybody have an idea what part of the code is choking up?
Also have that problem. 0.9.9 2002031104, Win98, Logitech Cordless Mouseman Wheel
*** Bug 136208 has been marked as a duplicate of this bug. ***
W2k SP2 Mozilla 0.9.9 talkback binary release Trust Ami Mouse Optical 200 (Driver Version 1.0)same Problem. Another Testcase: http://www.mozilla.org/quality/help/bugzilla-helper.html The Wheel scrolls the page as long as the Mousepointer is right of the Products Listbox(same with Bugzillas CC: Field) over, under or left of it it scrolls the Listbox. Works wenn i turn on MSIntelli Mouse compatibily in the drivers.
QA Contact: vladimire → tpreston
I have this problem with Mozilla 1.0 RC1, didn't have this problem with Mozilla 0.9.9 thought. Every page (so far) with a listbox will cause the scrollwheel to scroll the listbox instead of the page. It doesn't matter if I click somewhere or where my mouse is. On this page for example the mousewheel will scroll the CC listbox. On the Query Page it scrolls the OpSys box. On a page with just 1 item in the listbox the mouse wheel works fine. Expected results: Mousewheel scrolls the page. I'm running Windows 2000 SP2 and the Logitech MouseWare 9.42.1.66.
I downgraded to 0.9.9 and the bug still occurs, so I guess it was always in 0.9.9 but strangly enough I never noticed it.
*** Bug 139957 has been marked as a duplicate of this bug. ***
works for me... OS: Win XP Build:2002043010 I clicked everywhere in the form and tried to scroll using the mouse wheel. The page scrolls down... :)
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0rc2) Gecko/20020510 Windows XP, Moz 1.0 rc2 Mouse: Logitech Cordless MouseMan Optical using Logitech MouseWare Control Centre ver 9.42.1.66 Mouse Driver ver 9.42 I see this bug exactly as described, scrolling list boxes rather than the page unless I choose MS office compatible scroll only option in the mouse control centre. Would be nice to not have to use the workaround when Moz reaches 1.0 true.
This bug seems to have been fixed. Am using RC2 on Windows 2000. And the scrolling works as expected. There was a hardware change I made. I have a Kensington Optical PS2/USB mouse and recently connected the mouse to the PS/2 port instead of the USB port. Dunno if that is the reason for the "fix". If you want me to experiment between the two interfaces, let me know. BTW, the scrolling always worked for me with a similar mouse on Windows XP.
Still broken for me, Windows 98, RC2 (2002051006). I am using Logitech mouse, version 7.50.465 of drivers.
Stephan: USB or PS/2 interface?
Sorry about incomplete report - it is a PS/2 interface. Full data: Still broken for me, Windows 98, RC2 (2002051006). I am using Logitech mouse, version 7.50.465 of drivers. PS/2 Interface.
For those of you with Logitech mice, have you tried the latest 9.60.146 drivers? For me, it seems that this upgrade mostly fixed the problem. Why do I say "mostly fixed?" With "Use MS Office Compatible Scroll" off, the page scrolls. But so does the form element. For example, on a bugzilla page, if I scroll-wheel down the page moves, but the items in the "CC:" list will have also scrolled. I think this is still wrong, but it's far less annoying.
Yes - I can concur with Mike's observation. I upgraded Logitech drivers to 9.6x versions, and now on pages which have a list box, moving the mouse wheel scrolls both the page AND the list box. Still seems like incorrect behavior.
This is definitely not fixed. With build 2002-05-15-branch on WinNT and the older Logitech v8.6 driver (and PS/2), it still fails miserably unless you add the "Office97-compatible" option. The mouse-wheel only scrolls the 1st listbox no matter where you point or click. I also tested this on another NT machine where I upgraded the Logitech drivers from v9.4 to v9.6. Now, the scrolling works the same with or without the O97-compatible option. But I don't think Logitech's updates constitute a resolution to this bug. FWIW, I tested on IE 5.5 and it now works the same as Mozilla (using this mouse driver), i.e., neither will scroll simply by hovering over the page element -- you need to change the focus (click!) to make scrolling work. Also, some of the DUPEs for this bug are for Win98, so the OS= for this bug should be changed to Win98 (since it's the earliest version to exhibit the problem). Finally, the Release Notes still don't mention the Logitech option (which has to be the common solution, right?)...
Blocks: advocacybugs
What should the relnote for 1.0 say?
Keywords: relnote
How about this for the Release Notes: MOUSE WHEEL SCROLLING Windows: Mousewheel scrolling does not work with all drivers. If you have problems, try updating your driver or disabling any "helper" programs that your mouse uses. If you have a Logitech mouse, you can either upgrade the driver (to at least v9.60) or enable the "Microsoft Office compatible scrolling" option in the Mouse/Buttons control panel.
Superb. Please post that relnote to bug 133795.
*** Bug 145902 has been marked as a duplicate of this bug. ***
*** Bug 148590 has been marked as a duplicate of this bug. ***
*** Bug 134409 has been marked as a duplicate of this bug. ***
*** Bug 146791 has been marked as a duplicate of this bug. ***
as mentioned in the bug I logged today, I am using a dexxa optical scroll wheel mouse with the software provided by dexxaweb.com (v1.0 for windows2000). With this software enabled I can use both my left and right side buttons and scroll wheel in all applications except mozilla. In mozilla, the scroll wheel fails to work and appears to lock to a drop down. When I disable the software for the mouse, the scroll wheel works with mozilla, but all other functionality of the mouse, scroll wheel included, fails to work in any other application. Where do I go from here?
*** Bug 144028 has been marked as a duplicate of this bug. ***
I have the same problem here (see "Summary:") using Win2k Prof., Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0+) Gecko/20020502 and a Tevion MD-9602 (which looks like a relabelled logitech mouse. De-activating the drivers did not help (and the original logitech drivers don't do their job with the hardware :( ). Regards, Frederic Krueger
*** Bug 142802 has been marked as a duplicate of this bug. ***
*** Bug 155654 has been marked as a duplicate of this bug. ***
*** Bug 151497 has been marked as a duplicate of this bug. ***
Same problem e.g. on Bugzilla-helper page www.mozilla.org/quality/help/bugzilla-helper.html Please see bug 151497 for more details. With IE5/6 all works perfect, so it can not be a problem of the mouse-driver.
*** Bug 157103 has been marked as a duplicate of this bug. ***
I'm running Mozilla 1.1b under Win 2000 using a Logitek Trackman MarbleFX "mouse" (Actually a trackball that acts like a mouse) with the Logitek software that makes it do mouse-like things under Windows. Although the marble scrolls the window in Netscape 4.75, in Mozilla 1.1b it doesn't. That is, enabling the scroll mode and moving the trackball doesn't scroll any page in Mozilla. But on this bug report page is does scroll the "CC:" list. Maybe there aren't a lot of Logitek trackballs out there, but I use one to prevent the wrist injuries caused by mouses.
Come on guys! Netscape 7.0 is already out and this bug is still on the list, marked as NEW. And it's still on the bug 92997 (Bugs that make Mozilla advocacy harder) list. Man, this is embarassing...
Keywords: mozilla0.9.8 → mozilla1.2
If it'll make you feel better... The dependencies here are well documented; whining here does no good.
Status: NEW → ASSIGNED
Using Mozilla 1.1 20020826, on a new Fujitsu Lifebook S series with built-in touch-pad mouse and scrollwheel (button actually) this bug is back in force. I had fixed it on a logitech mouse on a different computer previously.
*** Bug 166850 has been marked as a duplicate of this bug. ***
On this very page and all other bug report pages, my mouse wheel scrolls the CC listbox rather than the page even when I haven't hovered over it. Also on the main bug list the page will not scroll via the mouse. I'm using Build 2002082606, WIndows ME.
Here's a comment I posted to bug 58589 before I found this one. Sorry that it's rather lengthy, but I don't think I am able to fully describe it much briefer. I have an interesting issue with my Memorex MX4350RF mouse that is probably related. The mouse has the common two buttons, a clickable wheel in the middle, plus two more buttons, one on each side, that are programmable. Among the functions that can be programmed for them are "Horizontal Wheel" and "Auto Scroll". (I'm talking about the Memorex driver, version 1.0, in Windows 98.) The former is supposed to toggle the wheel between vertical (the default) and horizontal scrolling. The latter displays a NSEW artifact, which is then a reference point for auto-scrolling in the direction the mouse cursor is placed with respect to it. Ugh... that is probably not a good description, but hopefully most of you know what auto-scroll means. You activate it, move the mouse a bit down and the document magically scrolls down until either you move the mouse back up or you deactivate the auto-scroll. The mouse driver also has a "Wheel Mode" setting that has two radio buttons: "System default (Intelli-Mouse) mode" and "Enhance scroll mode". Now, the weird part. Horizontal scrolling in Mozilla works perfectly in both modes, both with Horizontal Wheel and with Auto Scroll (although this might be just because I have not encountered a horizontally scrollable widget yet). However, vertical scrolling shows mixed results: 1) System default (Intelli-Mouse) mode: the wheel works fine, but AutoScroll doesn't (although the very same AutoScroll works for horizontal scrolling). 2) "Enhance scroll mode": both the wheel and AutoScroll work, UNLESS there is a vertically scrollable combo box on the page (perhaps it also applies to other v-scrollable widgets). If yes, it picks one (the first one?) of such widgets and it scrolls only this one widget, always. No matter where the cursor is when you roll the wheel, and no matter if you click somewhere before scrolling, and no matter if you use the wheel or AutoScroll. Thanks for your attention!
*** Bug 162955 has been marked as a duplicate of this bug. ***
This is unreal, this bug is still not resolved after more than two years. I have finished reading all the comments about this bug. I have to agree with one user that observes that mouse drivers work correctly with IE5/6 etc and many/most programs, so the bug is not in the mouse drivers it is in this program. For your information: Text boxes scroll but when you hit the end of the text box the page does not scroll which requires the user to click outside the text box to make the page scroll. If the text in the box is not long enough to scroll nothing happens at all with the scroll wheel until you click outside the box. Listboxes seem to scroll properly now! Pages scroll just not the text boxes. Setup: Windows XP Pro (not updated) Microsoft Wireless Intellimouse Explorer, Driver 4/11/2002 4.10.851.0 Mozilla 1.1 AMD 1600+ 256DDR 30GB Aside from another couple of problems with some sites (CNET) and an inability (so far) to get Mozilla to use Eudora as my email client I like it! Thanks people!
Scrolling still doesn't seem to work on pages containing listboxes (like this one). The listbox always gets scrolled, even if I try to set the focus to the page by clicking somewhere.
This is actually caused by a problem in the mouse drivers. I have a Logitech mouse and with the default setting, the problem appears, but when I go to the driver settings and select "Only use MS Office compatbile mousewheel" or so, the problem is gone. This happens because the mouse driver tries to *emulate* mouse whell scrolling in some applications that weren't programmed to work with it (if I enable this option, mouse wheel scrolling does not work in some applications were it used to work before!). This emulation doesn't work well together with some apps that were programmed to deal with mouse wheel scrolling. And no, it's not just Mozilla. I have the same problem in Forte Agent (news client). Unless I have enabled the option to only use office compatible mouse scrolling, the current NG overview and the NG list (or the message window) will scroll both at once when I use the mouse wheel. With the option enabled this doesn't happen. To me, as layman, the problem looks like this: Most apps are not supporting mouse wheel at all. They just open normal GDI windows and since Windows itself supports mouse scrolling (and thus all GDI components as well), Windows takes automatically care of the scrolling. Only some applications catch the mouse wheel event and perform the scrolling (or another action) itself (e.g. all games with MW support must do that). Mozilla does that as well, that's why you can select how many lines Mozilla will scroll in the preferences. Mozilla does not rely on Windows to handle MW automatically. But some mouse drivers try to emulate scrolling for components that actually do not support it. For these components neither Windows, nor the app itself takes care of scrolling. What now happens in Mozilla is that Mozilla catches the mouse event and scrolls the page accordingly, but to the mouse driver, it looks like the scrolling list has focus and the mouse driver will make the list scrolling. If I disable this MW emulation mode, it doesn't happen anymore. Since Mozilla is not really native Windows, it paints its own XUL components and supports skinning (without using the new skinning engine of WinXP), it may be confusing the mouse driver... however, Agent does as well and it is native Windows.
It might be wise to add "please read all previous comments first" to the summary or status of this bug. Some thing have been repeated over and over. However, I could not find the following. Although it was previously mentioned that for Logitech users installing the most recent drivers fixes this problem, this is not entirely true. If I visit this page, I can scroll down using my mouse wheel and when I click the CC listbox, I can scroll it. To scroll the page again, I have to click somewhere outside the listbox. So far everything works as expected (although it would be preferable if I could just scroll the listbox by hovering over it and would not need to click). However, if I scroll the page using the mousewheel after I have scrolled the listbox, the page and the listbox scroll at the same time. To see this (1) make sure that both the page and the listbox have been scrolled as I mentioned before; (2) make sure that both the page and the listbox have scrolled back to the their respective top sides; (3) scroll the page down using the mouse wheel; (4) go back to the top using PgUp or the scrollbar, but *not* the mouse wheel; (5) check the listbox: it will also have scrolled down. In practice, this is not a problem for me, but it's definitely not as it should be. (Win98SE, Logitech MouseWare 9.73.243)
> So far everything works as expected (although it would be preferable if I > could just scroll the listbox by hovering over it and would not need to > click). This would be completely untypical for Windows. All Windows default components only get focus when you click on them. What you describe is some kind of X-Mouse behavior (the focused is gained automatically by hovering it), but X-Mouse only applies to windows as a whole. I don't know of any app that behaves like you request. Also it would be very annoying if I always have to look what's under my mouse before I can scroll the page. > However, if I scroll the page using the mousewheel after I have scrolled the > listbox, the page and the listbox scroll at the same time. It doens't on my PC. I have Logitech mouse and just tried that. Everything goes fine. Have you made sure the option "Only use MS Office compatible scrolling" is checked in the drivers? Additionally you may want to check that scrolling only works in the currently active window. > (Win98SE, Logitech MouseWare 9.73.243) Well, I only have MouseWare 9.60.146 installed, but I doubt that the drivers have gotten worse in the meantime.
>> So far everything works as expected (although it would be >> preferable if I could just scroll the listbox by hovering over >> it and would not need to click). >> > This would be completely untypical for Windows. All Windows > default components only get focus when you click on them. Not so. Netscape 4.73 and MS Wheel mouse will scroll a widget when the mouse is over it, or the page when the mouse is not over any widget. This does not effect keyboard focus.
> Not so. Netscape 4.73 and MS Wheel mouse will scroll a widget > when the mouse is over it, or the page when the mouse is not > over any widget. This does not effect keyboard focus. That's also how my Logitech mouse behaves in those applications. I just checked IE6 and Opera 6.05. In both of them using the wheel mouse while you hover over the listbox makes both the page and the listbox scroll down. When you scroll all the way up and hover over the listbox, the listbox also scrolls up. However, there might be a problem with the Logitech driver: if I use Windows explorer to browse folders and both the tree view on the left and the contents window on the right do not fit in the window, using the wheel mouse scrolls both windows at the same time. I actually think tgos@spamcop.net is right in comment #165 about the way Windows apps *should* behave. It seems Logitech has adapted some of the X-mouse behaviour, and indeed if I check "Use MS Office Compatible Scroll Only" everything behaves correctly. Incidentally, in both cases I get the correct X-mouse behaviour when opening Opera 6.02 through a PuTTY/X-Win32 tunnel. So if I prefer that behaviour, I guess I'll just have to switch to Linux and in Windows the window should be activated by a click. :-) In short, in the case of Logitech mice it's very difficult to tell whether the problem is with Mozilla or with the drivers, but there are plenty ways to resolve it and make it work correctly. I don't know about other mice/trackball/driver combinations. Can anyone have the final word on this? It's embarrassing that this bug has been open for so long and it might not even be a Mozilla bug anymore.
> It's embarrassing that this bug has been open for so long and it > might not even be a Mozilla bug anymore. Embarrassing or not, it certainly seems to be a Mozilla issue, be it a bug, or a "feature" :^). Netscape 4.73 behaves at least consistantly and predicatably on my machine (WinNT4.0/MS Wheel Mouse) while Mozilla is spastic and unpredictable. That is... On Netscape, the widget scrolls when the mouse of over it, and the page scrolls when the mouse is not over a scrollable widget. On Mozilla, the page and random scrollable widgets take turns scrolling, regardless of the location of the mouse pointer, or keyboard focus.
workaround for Microsoft Intellipoint users: click on the systray icon, go to the "Wheel" tab, click "advanced", then check "Turn Off all Intellipoint software wheel support". The default setting disables it for IE only (Microsoft knows better, it seems).
Keywords: 4xp
> That's also how my Logitech mouse behaves in those applications. I just checked > IE6 and Opera 6.05. Not on my system. Neither in IE, nor in Opera, nor anywhere else.
No, you're wrong. Mozilla doesn't use native scrollbars, so while the mouse driver may correctly send WM_VSCROLL to a native scrollbar, it does not dispatch a WM_MOUSEWHEEL event. Complain to Microsoft, complain to the mouse vendor, but complaining here isn't going to do any good.
(To clarify, that was in response to the claims that this is a bug in Mozilla, not in the mouse driver).
I have not claimed it's a Mozilla bug. I strongly think it's a mouse driver bug, caused by the way how Windows applications work (that would be the fault of Micro$oft) and the way how mouse vendors writing their drivers to add functionality to applications (or Windows at a whole). Up to now I could disable the list-scrolling on every platform by either installing another driver (I had to do this for some noname mouses with very poor drivers) or by disabling a certain option in the driver (the last solution worked for Logitech and Micro$oft mouses and drivers... :shudder: Micro$oft mouses). Like I said, I also had this bug in other applications, not just Mozilla, so I had to disable this option in my mouse driver anyway. I will clear my vote for this bug (there are other bugs that annoy me much more... especially since this bug doesn't annoy me at all anymore since I disabled non-MS Office compatible scrolling in my Logitech driver) and I vote for marking this bug "WONTFIX" (it's design based, either mouse vendors stop enabling this annoying option by default in the configuration or Mozilla's event handling had to be re-written from the scratch... and let's face it, both won't happen).
tgos@spamcop.net opined that this is a mouse driver or windows bug, not a Mozilla bug. Please explain why Netscape 4.73 can handle wheel mouse scrolling flawlessly, with the same hardware, software and software configuration settings that cause Mozilla to be spastic in its behavior.
I haven't commented in over a year but I'd like to chime in again now. To repeat: DESIRED FUNCTIONS 1. ability to scroll entire page, by default, when first opened 2. ability to scroll listboxes by hovering (but not clicking them) PROBLEM The workarounds allow #1 but modify #2 so that you have to explicitly give the listbox focus (by clicking on them). ________________________ I agree with the people who are "blaming" Mozilla for this (I never had problems in any other programs) but it sounds like the problem is an unavoidable conflict between the need for Mozilla to utilize a single cross-platform method of scrolling versus the need for Windows mouse drivers to implement scrolling for the majority of Windows apps that don't expect scroll commands. If this is true then this bug should probably be WONTFIX and, instead, we need to create a new RFE to make Mozilla work better out-of-the-box on Windows. Maybe make Mozilla default to "dumb" windowing (that would work predictably with all Windows mouse drivers) and then include an "Advanced Scrolling" option in the Preferences? Can one of the programmers comment on this?
Like all (if I am correct) people above, I encountered this annoying behaviour if and only if the "Microsoft compatible scrolling" was disabled in the mouse driver. I do not consider switching this option on a valid workaround, as it breaks the "scroll while hover" functionality I usually get with having it switched off (also repeating only - this was said above, too). Examining Mozilla with Spy++ shows that there are two types of native Windows widgets in a form: * list boxes (only expanded ones, not collapsed ones), WindowClass "MozillaWindowClass" * the scrollbars besides the list boxes This at least explains why the bug does not happen with widgets other than these listboxes .... Again citing from above, the assumption is that in non-MS mode, the Logitec mouse driver finds the nearest scrollbar upon wheeling, and sends a scroll event to it, instead of sending the WHEEL event to the focused window (which is the default in MS mode). The attached patch prevents this by subclassing from the native SCROLLBAR widget: it registeres an own window class, which has the same characteristics as the native ScrollBar window, but a different class name ("MozillaScrollBar"). With this patch, I can leave "MS compatible scrolling" _off_ (this getting the "wheel on hover" functionality in applications other than Mozilla), but I get the "wheel focused" behaviour in Mozilla. Means, when I click (and thus focus) the main window, then the main window is scrolled when wheeling. I consider this an improvement about the old behaviour, which was scrolling the listbox no matter where the focus is.
Attached patch patch with UNICODE support (obsolete) — — Splinter Review
i hope this is equivalent, i haven't compiled it and i don't have a wheel mouse :). a few notes, 1. tabs are taboo, patches should follow the modeline (which calls for 2 spaces), patches should follow local style ("when in rome"), in this file spaces aren't used to pad parens. 2. we're moving to using microsoft unicode layer, so we need to patch the unicode version of the code.
Nice find! I'm curious if this breaks any other aspects of the native scrollbars, such as picking up the themed look on Windows XP. That broke at one point as MOZ_UNICODE was being turned on when we accidently started using "MozillaWindowClass" as the window class for scrollbars. The fact that you're subclassing "SCROLLBAR" may prevent that problem from happening though. I'll test this on XP when I get a chance.
Comment on attachment 103636 [details] [diff] [review] patch with UNICODE support Doesn't break the XP look on the scrollbars, and everything seems to work fine with this patch (although it worked fine on my system before this patch, too). I'd like to get some wider testing on this patch before landing it, but I'll go ahead and mark r=bryner.
Attachment #103636 - Flags: review+
Attachment #103613 - Attachment is obsolete: true
timeless, sorry for not doing like the romans. I admit that I defaulted to these tabs because I encountered a lof of files in the mail/news area where the header claims "tab=4 spaces", and the body has all possible (and impossible) styles (even within one file), so I became a little bit sloppy in respecting what the header says :). Sorry. For your attachement 103636: Shouldn't sScrollbarInited be a static member? And, more important, be initialized somewhere?
brian, can you please test attachment 103636 [details] [diff] [review] on XP, again? I suspect that the non-initialized sScrollbarInited means that the subclassing never happened, as chances are good that sScrollbarInited has some non-0 value all the time.
new unicode-enabled version (thanks for pointing me to this, timeless), this time in a hopefully roman style :), and with a static initialize-flag.
would like to mark attachment 103636 [details] [diff] [review] as obsolete, but don't have the rights to do so - where do I have to apply for? :)
Comment on attachment 103636 [details] [diff] [review] patch with UNICODE support superseeded by attachment 103736 [details] [diff] [review]
Attachment #103636 - Attachment is obsolete: true
Comment on attachment 103736 [details] [diff] [review] Unicode-enabled version with static/initialized member I'm worried about these #defines clashing with other #defines in the future, since they are fairly generic. Please use an enum or static const int's. Also, what would cause registering the window class to fail?
Attachment #103736 - Flags: needs-work+
If you move the mouse over the page's scroll bar (kinda like gtk) it will scroll the page.
Attached patch updated version using an enum (obsolete) — — Splinter Review
complying to Brian's request. Brian, I admittedly do not know reasons why RegisterClass could fail - MS' documentation is pretty sparse about this. I rarely saw code really handling a the registration failing (not even with a fallback), so I have no clue ...
Attachment #103736 - Attachment is obsolete: true
*** Bug 178111 has been marked as a duplicate of this bug. ***
*** Bug 162643 has been marked as a duplicate of this bug. ***
Comment on attachment 104336 [details] [diff] [review] updated version using an enum Brian, could you please have a look at the patch in case you find some minutes? Thanks :)
Attachment #104336 - Flags: review?(bryner)
Comment on attachment 104336 [details] [diff] [review] updated version using an enum Get rid of the hard tabs you added to nsScrollbar.h and r=bryner.
Attachment #104336 - Flags: review?(bryner) → review+
Attachment #104336 - Flags: superreview?(dbaron)
Attached patch no more tabs ... — — Splinter Review
thanks Brian ....
Attachment #104336 - Attachment is obsolete: true
Attachment #106335 - Flags: superreview?(dbaron)
Attachment #106335 - Flags: review?(bryner)
Could you ask someone who knows the Windows APIs / widget code (rods? kmcclusk?) to review this, and then have bryner convert his r to sr? I don't feel qualified to review this.
Attachment #106335 - Flags: superreview?(dbaron)
Attachment #106335 - Flags: review?(rods)
Attachment #106335 - Flags: review?(bryner)
This is pretty straight-forward code. dbaron, will you accept a review by me? Windows programming is my day job, after all.
Comment on attachment 106335 [details] [diff] [review] no more tabs ... seems like the right thing to do
Attachment #106335 - Flags: review?(rods) → review+
Attachment #106335 - Flags: review+ → review?(rods)
Comment on attachment 106335 [details] [diff] [review] no more tabs ... Seems ok r=rods
Attachment #106335 - Flags: review?(rods) → review+
ok, i checked in a compiling version of this. frank if all is well please resolve this as fixed.
Assignee: bryner → frank.schoenheit
Status: ASSIGNED → NEW
> ok, i checked in a compiling version of this. thanks a lot. Sorry, should have asked for this earlier, lost this from the radar a little bit .... > frank if all is well please resolve this as fixed. will do.
I can't reproduce with 2002121108-trunk/WinXP and A4tech WOP-35. Thanks! I'm very comfortable!!
Bugzilla-jp has a report. Reporter can reporoduce this problem. With 2002121108-trunk/Win98 and Logitech Wheel Mouse(driver version as 8.40). If you have same system, you test this problem. http://bugzilla.mozilla.gr.jp/show_bug.cgi?id=2160#c9
from Bugizlla-jp. We have two reports. 1. The problem of #200 is not reproduced by upgradeing the driver 8.40 to 9.75. 2. Another reporter said, he can reproduce this problem with IBM Scrollpoint pro(IBM Mouse Suite ver2.47) and 2002121108-trunk/win98.
Masayuki: There's a good chance the fix may not be in the 2002121108 build referenced in your last two comments, since timeless only made the comment about checking in the fix two hours earlier. Ask the reporters to try a newer build.
But...See #199. I could reproduce this problem with 2002121104-trunk/WinXP. But I couldn't reproduce this problem with 2002121108-trunk/WinXP.... Now, I ask to the reporter.
Build ID 2002121204, Win 98 Microsoft Intellimouse Optical USB, tested on this Bugzilla form. If focus is in the text entry box then the wheel scrolls the text entry box regardless of where the mouse pointer hovers. If focus is elsewhere then the wheel scrolls the page regardeless of where the mouse pointer hovers.
OK, now for something weird, because I've read that the bug really is with listboxes. I used the CC listbox on this page for testing. I enter the page and don't click anything. I stay away from the listbox and the page scrolls OK. If I hover over the listbox and wheel down then the page goes down, but so does the listbox. I can wheel back up and the listbox has now paged down one level (because the wheel-up was outside the listbox which has scrolled off the top of the screen). Repeating this down and up wheeling eventually gets to the bottom of the listbox. If I attempt to wheel up while hovering over the listbox then the page doesn't move, although the listbox will scroll up until I am at the top of the list. Now, having done this, wheeling down no longer affects the page but pages the listbox up and down. Moving the mouse pointer away from the listbox returns to scrolling the page. I'd say not fixed yet, based on the behaviour I think you want.
The reporter(in 2nd of comment #201) reported. He tested with 2002121608-trunk/win98, he can reproduce this problem....
On OS/2 Warp, Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.2.1) Gecko/20021201 also scrolls only the listbox on this page and not the page. This only happens if the wheel mouse driver is set to issue scroll messages, with cursor keys it does not happen.
Summary: [MW]Mousewheel scrolling scrolls listbox, not page → [MW] mouse wheel scrolls listbox, even when cursor is outside listbox
Possible dups: bug 70666, bug 185925.
*** Bug 185925 has been marked as a duplicate of this bug. ***
Blocks: 140346
Keywords: mozilla1.2 → mozilla1.3
*** Bug 189913 has been marked as a duplicate of this bug. ***
Blocks: majorbugs
comment 201 > 2. Another reporter said, he can reproduce this problem > with IBM Scrollpoint pro(IBM Mouse Suite ver2.47) and > 2002121108-trunk/win98. he said that he can _not_ reproduce this problem with 20030605/trunk-win98. (he doesn't change mouse driver)
-> FIXED per comment 197 and last comment which confirms all is well.
Status: NEW → RESOLVED
Closed: 25 years ago → 20 years ago
Resolution: --- → FIXED
No longer blocks: majorbugs
*** Bug 203519 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: