Closed Bug 33732 Opened 24 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: 24 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: 24 years ago → 24 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: 24 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: