Closed Bug 31500 Opened 25 years ago Closed 24 years ago

Mouse Wheel Scrolling

Categories

(SeaMonkey :: General, defect, P3)

Product:
SeaMonkey
Component:
General
Platform:
x86
Windows NT
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: robertgee, Assigned: bryner)

References

(
URL
)

Details

Microsoft mouse wheel scrolling does not begin working until cursor is located

over right hand scroll bar, and the mouse wheel itself is clicked. One IE 5.0,

mouse scrolling is always activated on all pages.
Reassigning to bryner@uiuc.edu who is the mouse wheel scrolling guru.

robertgee@worldnet.att.net, can you give more information about your system? 
Please read the Bug writing guidelines at 
<http://www.mozilla.org/quality/bug-writing-guidelines.html>
Assignee: cbegle → bryner
Just to note that I am looking at this, but I can't do anything until you give
some more information, including:

Mozilla build version
Mouse driver version

Also, are you referring to regular wheel scrolling or to the "wheel-pressed"
mode where you hold down the wheel button and move the mouse?

Hi, I am using a Micron Millennia PC and Windows NT4 SP4 with a Micron branded 
Microsoft scroll wheel mouse using "Pointer device using msi8042".  Mozilla is 
M14 build 2000022820.  Just bring up www.news.com, and the scroll wheel will 
not work.  Pressing the scroll wheel itself will allow the page to scroll by 
physically moving the mouse which is not what I wanted.  I really want to 
scroll the HTML page with the scroll wheel only.  If you need more information, 
please feel free to send me an e-mail.  Thanks.
Can you take a look on a current nightly build (i.e. 03-16-2000-M15 or later)
and let me know if this is still happening?  The problems you're describing
sound similar to bugs 22794, 25708, and 20618.  You might also want to see the
comments I added to those bugs about the logging option I just added to the
nightly builds.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Status: NEW → ASSIGNED
robertgee@worldnet.att.net:

Can you please update the status on this bug, when you have a chance?  Thanks.

In case robertgee@worldnet.att.net doesnt respond... with build 2000033116 the 
problem is still evident.  Scrolling the mouswheel does not scroll the page.  
If you click on the main scroll bar with the mousewheel then the page does 
scroll as you move the mouse up and down.  It continues to move with the mouse 
movement until you left (or right) click in the document.  Kinda weird.  Also  
you can scroll selection boxes like the ones in 
http://bugzilla.mozilla.org/query.cgi normally.
Heres my pertinent hardware/software: Win95b, Microsoft PS2 IntelliMouse with 
Intellieye, Microsoft IntelliPoint 3.0 (I might have upgraded to 3.1a, can't 
remeber) driver which runs a deamon called Point32.
I'll check out the logging thing in the nightly builds next :-)
I take back what I said.  I don't understand the logging stuff in the other 
bugs.  Do you have to build Moz to do that or can you enable it in a binary?  
To be honest I don't even have a compiler installed in windows.
No, you don't have to build Mozilla to use the logging.  Just go to an MS-DOS
prompt, type:

set NSPR_LOG_MODULES=MOUSEWHEEL:5

then cd to the mozilla directory and run:

mozilla > mozilla.log

The mozilla.log file will contain the logging information, if anything got
logged.

From your description, I'm wondering if this is really the same as all of the
other "scrolling doesn't work" bugs, and the scrollbar thing is simply a
workaround.  See bugs 32226, 20618, 22794, and 25708.  If one of those other
bugs describes this bug I would rather not keep this one open.

Wow! this is cool stuff.  I got your copy of gkwidget.dll working! I renamed 
the original gkwidget.dll to something else and put yours in it's place.  I 
then loaded mozilla with the "> mozilla.log" option. Then I let mozilla come up 
and I moved the Mousewheel down once.  I then closed Mozilla with alt-F4.  An 
examination of the .log file produced this line early on: "Registered 
MSH_MOUSEWHEEL = 52347" and then the fifth to last line:"nsWindow received 
MSH_MOUSEWHEEL, HWND=608"  Pretty cool.
OK, I just tried the same experiment except I scrolled the mouswheel up once.  
It was identical except the fifth to last line was now:"nsWindow received 
MSH_MOUSEWHEEL, HWND=2376"
Playing around some more... it seems the HWND number is arbitrary.  Each time I 
bring up mozilla, move the mouse wheel and then look at the log file, it seems 
to be a differant number regardless of wether I moved the wheel up or down.  
For example, moving it up once then down once made these to lines in the .log 
file: 
nsWindow received MSH_MOUSEWHEEL, HWND=3592
nsWindow received MSH_MOUSEWHEEL, HWND=3592
if I do the same thing again...
nsWindow received MSH_MOUSEWHEEL, HWND=3248
nsWindow received MSH_MOUSEWHEEL, HWND=3248
I don't get it, what is the significance of the numbers?

I took a look at the four bugs you mentioned.  I don't think this bug is a dup 
of 32226 (both Microsoft mice yes, but that bug is intermittent for some 
reason, while this bug is constant).  I've looked at the other three briefly 
but I'll have to look in them more deeply later.
Ok, so.... you are seeing the MSH_MOUSEWHEEL messages, but the content area is
not scrolling?  This could be important, as it means I know where to look now
for the bug.

Were there any additional lines printed after you moved the mousewheel?

No, no lines are printed after moving the scroll wheel aside from the usual 
nsWindow received MSH_MOUSEWHEEL, HWND=XXXX  Interestingly, clicking the 
mouswheel causes "OH MY GOD!" to be printed out?!  By the way, everything works 
fine when gfx scrollbars are turned off.
As of the nightly build of April 4, 2000, this bug appears to have been fixed.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
fisher7@thegrid.net:

I've updated the version of gkwidget.dll at
http://www.productivity.org/~bryner/mozilla/gkwidget.dll

to include different debugging information.  I'm especially interested to see 
what it prints for you, since it looks like we get really close to handling the 
scroll correctly but then it somehow does not.  So please give it a try when 
you have a chance.  Thanks.

Updated gkwidget.dll again, only change is to remove some extraneous debugging 
output that was printing out even when there was no mousewheel movement.

bryner@uiuc.edu:
Sorry, here is the error message mozilla crashes with when running the new 
gkwidget.dll:

MOZILLA caused an invalid page fault in
module APPSHELL.DLL at 0137:60035a71.
Registers:
EAX=0068fcd8 CS=0137 EIP=60035a71 EFLGS=00010246
EBX=00000ffe SS=013f ESP=0068fc94 EBP=0068fcb8
ECX=00000064 DS=013f ESI=0068fc80 FS=3fd7
EDX=00000001 ES=013f EDI=00000000 GS=0000
Bytes at CS:EIP:
ff 11 8b f8 8d 4d fc e8 57 80 00 00 8b c7 5f 5e 
Stack dump:
0068fcd8 60046098 0068fcf8 00000000 80000000 60040000 00000000 00000001 
00c07200 0068fcfc 600353e8 00889620 00000000 00c06420 00000000 00000000 

And here is what it writes to the log file before it crashes:

Profile Manager : Profile Wizard and Manager activites : Begin
Profile Manager : Command Line Options : Begin
Profile Manager : Command Line Options : End
ProfileManager : GetProfileDir
ProfileManager : GetProfileDir
Profile Manager : Profile Wizard and Manager activites : End
has multiple monitor apis is 0
****** number of sceens 1
WEBSHELL+ = 1

I tried downloading it twice in case it got corupted in the transfer, it didn't 
change anything.  I'll download the April 4, 2000 build to see if it works as 
per robertgee@worldnet.att.net 's comment.

Also, I took a look at the three other bugs.  I suggest we move over to bug 
20618 (not a perfect match but close enough) since this bug is closed.
I compiled that against the current source... are you running the 04-05 nightly?
Oh, no wonder :-)  OK, running with build 2000040415 with new gkwidget.dll,
scrolled mousewheel down once, up once, and down once.  Then closed program.
The log file:

Document: Done (4.62 secs)
Processing mousewheel message
Getting scroll lines
Got iDeltaPerLine=0
Processing mousewheel message
Got iDeltaPerLine=0
Processing mousewheel message
Got iDeltaPerLine=0
WEBSHELL- = 2
WEBSHELL- = 1
~nsProfile
WEBSHELL- = 0

Ah, that would do it!  Looks like we're failing to read the system setting for 
number of lines to scroll, and therefore bailing.  I think I need to make 
separate cases for WM_MOUSEWHEEL and MSH_MOUSEWHEEL to read the number of 
lines.  Will try to get that done in the next couple of days. (I'll put up a 
new gkwidget.dll and update this bug so you can check it out before I check it 
into the tree).

Awesome!  Awaiting your word...

Ok, no guarantees, but I just uploaded a new gkwidget.dll that attempts to 
properly detect the system setting for the number of lines to scroll on Win95.  
Give it a shot.

Congratulations!  It works beautifully!  Thank you!  Here's the log from one 
mouse scroll:

Document http://www.mozilla.org/ loaded successfully
Document: Done (4.56 secs)
Processing mousewheel message
Getting scroll lines
Using Win95 mousewheel handling
Got mswheel hwnd
Registered MSH_SCROLL_LINES
Got ulScrollLines = 3
Got iDeltaPerLine=40
Dispatching message to another window
Giving message to window with hWnd=744
Processing mousewheel message
Got iDeltaPerLine=40
Setting scrollEvent.deltaLines=-3
Calling DispatchWindowEvent for mousewheel message
WEBSHELL- = 2
WEBSHELL- = 1
~nsProfile 
WEBSHELL- = 0

The "click the mousewheel scrolling" doesn't work, but I bet you knew that 
already.  Thanks again...
Congratulations to bryner and fisher7 for their great work!  I can't wait to 
download Netscape 6 Preview 1.  Maybe in the future, I can contribute my C++ 
development skills instead of just testing.
Thanks.  You should note, though, that Netscape 6.0 PR1 was branched off 
several weeks ago and so won't contain any of the recent fixes.

Works for Me
Platform: PC
OS: Windows 98
Mozilla Version: 2000100508

Marking as Verified
Status: RESOLVED → VERIFIED
transferring these to my netscape.com email.
Assignee: bryner → bryner
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.