Closed Bug 63463 Opened 24 years ago Closed 22 years ago

Mac mousewheel doesn't work with kensington scroll mice

Categories

(Core :: XUL, defect)

Product:
Core
Component:
XUL
Platform:
PowerPC
Mac System 8.5
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla0.9.3

People

(Reporter: mikepinkerton, Assigned: mikepinkerton)

References

Details

(Keywords: helpwanted, Whiteboard: can't verify until new kensington driver) 

We haven't yet tested to see if the scrollwheel support works with kensington
scroll mice.

anyone have one of these?
Status: NEW → ASSIGNED
Keywords: nsmac1
Target Milestone: --- → mozilla0.9
ok, i hear that it doesn't work. any ideas? anyone have one of these?
Keywords: helpwanted
Summary: Verify Mac mousewheel with kensington scroll mice → Mac mousewheel doesn't work with kensington scroll mice
*** Bug 64724 has been marked as a duplicate of this bug. ***
Target Milestone: mozilla0.9 → mozilla0.9.1
I can verify that it does NOT work with my Kensington Mouse-In-A-Box Optical Pro
with MouseWorks 5.60.
Forgot to mention that this is on Mac OS 9.1, so it spreads beyond just 8.5.
can someone with a kensington mouse take a look at this?
Target Milestone: mozilla0.9.1 → mozilla1.0
I have kensington 5.60 with a turboball, and the wheel doesn't work.. Kensington
is huge on Mac, and i've seen lots of complaints from mac peeps on irc,
versiontracker, user forums, etc.  Chief complaints were lack of mousewheel
support (2nd to general sluggishness), I would love to see this one fixed in 6.5.

I have an extra Kensington Orbit trackball USB, if somebody wants to borrow it
please come to my cube
ok, i tried calling someone at Kensington, but all i got was voicemail. we'll see 
if he calls me back ;)

i instrumented our event loop and it appears that we're not getting _any_ events 
from teh mousewheel driver. if we don't, i can't tell how it would work, and thus 
can't get it working :(

anyone know a developer at kensington?

pulling back. spoke to someone at kensington and they will be able to help with 
some specifics. given what we discussed on the phone, i think i may even have a 
good solution by then end of the day.
Target Milestone: mozilla1.0 → mozilla0.9.1
nice!

i'm closer, here's what i've found:

- the scrollbar has to be 2 pixels wide
- the scrollbar has to be on the right side of the window (to the right of the 
mouse)
- the scrollbar has to be w/in the content area

right now, it works, but the placement of the phantom scrollbar interferes with 
the mozilla scrollbar and all hell can break loose. :(

i'll keep chugging. this may require some changes to the driver itself.
Target Milestone: mozilla0.9.1 → mozilla0.9.2
currently in contact with kensington. current status is that they are probably
going to have to rev their drivers to work with mozilla.
Target Milestone: mozilla0.9.2 → mozilla0.9.3
i have a small patch to this to make it work with a forthcoming driver. I want to 
take this for RTM. r=pchen/sr=hyatt.

patch:

Index: mozilla/widget/src/mac/nsMacWindow.cpp
===================================================================
RCS file: /m/pub/mozilla/widget/src/mac/nsMacWindow.cpp,v
retrieving revision 1.93
diff -u -2 -r1.93 nsMacWindow.cpp
--- nsMacWindow.cpp	2001/07/02 22:22:01	1.93
+++ nsMacWindow.cpp	2001/07/17 18:41:21
@@ -567,5 +567,5 @@
   //
   // Luckily, NONE of this is required on OSX, which uses CarbonEvents ;)
-  Rect sbRect = { 100, 0, 200, 1 };
+  Rect sbRect = { 100, -1, 150, 1 };
   mPhantomScrollbarData = new PhantomScrollbarData;
   mPhantomScrollbar = ::NewControl ( mWindowPtr, &sbRect, nil, true, 50, 0, 100,
Whiteboard: PDT+
landed on trunk. no way to verify until kensington releases their updated driver.
Keywords: nsBranch
Whiteboard: PDT+ → PDT+, on trunk, needs to go on branch
Who approved this for PDT+?  I'm taking the marking off until that is explained.  

Now, why should this be PDT+?
Whiteboard: PDT+, on trunk, needs to go on branch → on trunk, needs to go on branch
OK, putting PDT+ back now that we've discussed this a bunch.  If you can, please
check in tonite so this is in the morning's build.
Whiteboard: on trunk, needs to go on branch → PDT+; on trunk, needs to go on branch
jag checked it in on the branch.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
removing PDT+ to remove from "hit list", since this is checked in, but can't be 
verified
Whiteboard: PDT+; on trunk, needs to go on branch → can't verify until new kensington driver
bring me the hand of a kensington mouse user that is running the new driver(s)! ;-)
ain't no such driver (yet) ...
pink can prolly get a beta of the new driver through his contacts at Kensington.

i have a copy of the driver, but it's pre-release and won't ship until after we 
ship. i can't attach it, for obvious reasons.

*** Bug 98361 has been marked as a duplicate of this bug. ***
*** Bug 103096 has been marked as a duplicate of this bug. ***
Any word on when this driver will ship?  I'm worried that Kensington's efforts
have shifted solely to OS X drivers.  (Granted, I will be on OS X eventually,
but until then I'd like to be able to use my scroll wheel in Netscape 6.2 on OS
9.2.1)
You should contact Kensington directly about that.
From an e-mail I received from Kensington:

The new version of Kensington Mouseworks is going to be version 5.7 for MAC OS
9.x. We are working on the software, but like you said, we are focusing more on
the OS X software. Mouseworks 5.7 should be completely very soon and be released
by the end of November or early December. This is not definite, but it a
possibility. Our developers have been working overtime because of Windows XP and
MAC OS X. I am sorry for the delay, but we will be coming out with the update soon.
Be advised that Kensington has shipped their version 5.7 software and it does,
in fact, successfully activate scroll wheel functionality in Mozilla.
Well, it does work fine on many pages.  On this bugzilla page, however, the
behavior is a bit erratic.  Depending on where you click either the page will
scroll or a line of the text will highlight.  Is there any particular rule as to
where on a page to click to promote scrolling?
Yay!
Totally messed up since Mozilla 0.9.8.  I was hoping that some of the scrolling
changes implemented since would make Mozilla 0.9.9 (build 2002031106 on Mac OS
9.2.2 with MouseWorks 5.7) would have fixed this, but it hasn't.  I can only get
it to scroll (and not even close to as smoothly or as quickly as Netscape 6.2.1)
by moving the cursor over an image or a text link.  Naturally this only works
for a couple of lines, as the image or link will no longer be under the cursor
once the page scrolls.  (I noted in several other bugs that this was no longer
working for me, but seeing as those comments were ignored, I thought I'd come
back to this one.)
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Ugh!  So much for my grammar!

A better phrasing:  I was hoping that some of the scrolling changes implemented
since then would make my mouse's scroll wheel work properly under Mozilla 0.9.9
(build 2002031106 on Mac OS 9.2.2 with MouseWorks 5.7), but it doesn't.
It seems to vary somewhat page by page and under varying conditions.  For
instance, on this page if the text box is in the visible window area, the page
won't scroll at all; when I scroll past it, the page will scroll, but VERY
SLOWLY -- I have to drag it with all my finger to move it one line.  It may be
scrolling somewhat, but I wouldn't call it "working."  ;-)
please file a new bug. this was laid to rest ages ago.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 22 years ago
Resolution: --- → FIXED
I'd like to ask a question here since I haven't seen a new bug yet as pink
requested - does the scrolling behavior differ if the cursor is directly over
the scroll bar instead of somewhere in the window content area?
Please refer to bug 123172, a bug that I filed quite a while back which was
initially marked as a duplicate of a scroll wheel issue "catch all" bug but that
I now have reopened.
You need to log in before you can comment on or make changes to this bug.