Closed Bug 22794 Opened 25 years ago Closed 25 years ago

Wheel mouse is not working/Genius NetMouse

Categories

(Core :: DOM: UI Events & Focus Handling, defect, P3)

Product:
Core
Component:
DOM: UI Events & Focus Handling
Platform:
x86
Windows 95
Type:
defect

Tracking

()

Status:
VERIFIED DUPLICATE of bug 20618

People

(Reporter: kamnet, Assigned: bryner)

Details

(Keywords: platform-parity, Whiteboard: [nsbeta2-])

I'm using build M12 Build ID #1999122023. I have a Genius NetMouse Pro on Windows 95C with IE 5.0 & NS 4.08 installed. Genius NetMouse Pro Control Panel version is 4.19.00; Genius Netmouse Pro Driver is version 4.19.00. This problem is similar to Bug #20618 -- the scrolling button on the mouse does not scroll the windows in Mozilla, but works fine in other applications. I went to Edit->Preferences->Debug and disabled gfx scrollbars. After restarting Mozilla, the scrolling button works as expected.
Assignee: nobody → bryner
mousewheel->bryner@uiuc.edu
Status: NEW → ASSIGNED
Does the Genius Netmouse have a background program that handles scrolling? Also, can you get me a URL for the company that makes this mouse? Thanks.
Yes, it uses a background program which allows it to scroll in applications which do no support such mouse functions natively. The application name is 'gmnet'. The company website is at http://www.geninusnet.com.tw/ or http://www.genius- kye.com/ .
If you temporarily kill gmnet, can you then scroll in Mozilla with gfx scrollbars turned on?
Marking M15, like the logitech bug. Updating component and QA contact.
Component: Browser-General → Event Handling
QA Contact: nobody → janc
Target Milestone: M15
Keywords: 4xp, pp
Beginning with the 03-16-2000 M15 builds, you can do the following to generate mousewheel debugging information (on Windows): set NSPR_LOG_MODULES=MOUSEWHEEL:5 mozilla > mozilla.log Mousewheel debugging information will have this format: 1024[80589f0]: (message) Note that the numbers may differ. If you are having the problems described in this bug, and see any of these messages in the generated mozilla.log, please attach the log to this bug report. If you don't see these messages, the problem is the app not getting the event in the first place (which is what I suspect, but I want to be sure).
So far as I can tell, you are correct. I've set NSPR_LOG_MODULES as advised and run mozilla -console and while I see other debug messages, I see nothing in response to mousewheel movement, either with gfx scrollbars or without.
Ok, that would seem to indicate that mozilla isn't receiving the WM_MOUSEWHEEL message at all. I plan to check in a patch soon to let mozilla recognize the MSH_MOUSEWHEEL message. I can't guarantee it will help this particular situation, but it does seem that this message is used instead of WM_MOUSEWHEEL at least by some Win95 mouse drivers. Unfortunately, on the only Win32 machines I've tried Mozilla on, mousewheel scrolling works fine, so this is a bit difficult for me to debug.
Understood. We'll try to give you as quick turn-around as possible.
For what it's worth, I checked in some code today to let mozilla recognize MSH_MOUSEWHEEL messages that are apparently generated by some mouse drivers on Win95. Might make scrolling work in some cases where it did not before. This will show up with the next nightly builds, which will be 3-20, I think.
I downloaded build 2000031908. No messages of any kind show up under MOUSEWHEEL:5 and the gfx scrollbars continue to ignore the Netmouse "mousewheel" actions. If I turn on all:5 logging and turn off gfx scrollbars, then moving the mousewheel gives "CreateInstance" messages, but I'm fairly sure that these are not from the mousewheel per se, but from scrolling.
You might want to look at info I just added to bug 20618 about how to get even more debugging output.
Summary: Genius NetMouse browser button fails to scroll in M12 default settings → Wheel mouse is not working/Genius NetMouse
Target Milestone: M15 → M16
Please try retesting this with a build from 2000-04-12-M16 or later. Thanks.
Perhaps I'm doing something wrong. I have build 2000041308 with talkback for NT. With the gfx scrollbars on, I get no response from the mouse "wheel" at all. I ran it with mousewheel logging and see nothing listed in the console when I do something with the mouse. I even downloaded gkwidget.dll as mentioned in the other bug and tried that, but it seemed to make no difference. Sorry!
Moving all my bugs to this email.
Assignee: bryner → bryner
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
Blocks: 33732
nominating for nsbeta2, because the new dependency is nsbeta2+
Keywords: nsbeta2
Putting on [nsbeta2+] [will be minus on 6/15] radar.
Whiteboard: [nsbeta2+][will be minus on 6/15]
No longer blocks: 33732
Just a note, this is one of a class of mousewheel bugs (including 20618, 39335, 25708, and 40986) that I have not been able to reproduce for myself nor make any progress on fixing. Therefore, I do not anticipate this being fixed before 6/15.
6/15 has passed, and clearly folks are too doomed to be able to handle this. Changing to beta2 minus
Whiteboard: [nsbeta2+][will be minus on 6/15] → [nsbeta2-]
M16 has been out for a while now, these bugs target milestones need to be updated.
With the gfx scrollbars now a requirement, this is a much more significant issue. I don't know if the genius netmouse is the only one with this problem, but thos who have it are now unable to use the rockerbar in Mozilla.
Severity: minor → normal
Clearing target milestone. I'm tempted to mark this a dup of 20618 and use that as a meta-bug to track mousewheel-not-working problems on win32. It's quite likely the exact same issue. Anyone object to this?
Target Milestone: M16 → ---
I'm consolidating this bug with 20618. *** This bug has been marked as a duplicate of 20618 ***
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
Mass update: changing qacontact to ckritzer@netscape.com
QA Contact: janc → ckritzer
verified dup
Status: RESOLVED → VERIFIED
Just downloaded build M17, ID# 20000807. Genius Netmous still does not work in scrolling scrollbars up or down. As suggested by ckritzer@netscape.com, I am re- opening this bug.
Status: VERIFIED → REOPENED
Resolution: DUPLICATE → ---
No... by reopening it you are saying "this isn't really a dup". I'm remarking this a dup. Please follow bug 20618. *** This bug has been marked as a duplicate of 20618 ***
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → DUPLICATE
vrfy dup
Status: RESOLVED → VERIFIED
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.