Closed Bug 309344 Opened 19 years ago Closed 19 years ago

Scrollwheel doesn't work when an java applet is displayed

Categories

(Core Graveyard :: Widget: Mac, defect)

Product:
Core Graveyard
Component:
Widget: Mac
Version:
1.8 Branch
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: danny.bloemendaal, Assigned: smichaud)

References

Details

(Keywords: fixed1.8.0.2, fixed1.8.1, regression, Whiteboard: [rft-dl])

Attachments

(1 obsolete file)

User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4 Go to a site with a java applet on it and scrolling (at least with the touchpad (double fingers on the latest powerbook)) stops working in all tabs. Even closing the page with the applet doesn't restore the problem. Browser restart is necessary. Reproducible: Always
Which version of Mac OS X are you running? And please give more detail about which model PowerBook you're using. If you're running OS X 10.4.2 (Tiger), it's likely that your problem is caused by a bad interaction between the Java Embedding Plugin (now being bundled with Firefox, Camino and SeaMonkey alphas/betas/nightlies) and a buggy trackpad driver from Apple. See: http://sourceforge.net/tracker/index.php?func=detail&aid=1280969&group_id=107955&atid=649116 http://javaplugin.sourceforge.net/
Assignee: nobody → joshmoz
Ok, I'm running the latest osx version: 10.4.2 and the latest 15" powerbook: Machine Name: PowerBook G4 15" Machine Model: PowerBook5,6 CPU Type: PowerPC G4 (1.2) Number Of CPUs: 1 CPU Speed: 1.67 GHz L2 Cache (per CPU): 512 KB Memory: 1 GB Bus Speed: 167 MHz Boot ROM Version: 4.9.1f1
I'm experiencing this also, however in my case, it only affects the tab containing the applet. I'm also experiencing it on sites that contain javascript that watches mouse events, and NO JAVA on the page, which leads me to believe that it isn't strictly JEP's fault (JEP shouldn't be active on a page that has no Java, right?). Example site: http://www.gbgm-umc.org/holland-fumc/index2.htm This is a major usability issue for people with Powerbooks, so nominating for blocking. It might not actually be worth it (after all, it's an optional feature on the trackpad, and it's off by default), but it is the kind of minor little issue that might generate bad reviews if someone using a Powerbook reviews the app after the 1.5 release.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking1.8rc1?
(In reply to comment #3) > I'm experiencing this also, however in my case, it only affects the tab > containing the applet. OK, I'm mistaken here, it does take out the scrolling in the entire window. I had two different windows open and was testing in the wrong one when I said that.
This is really an Apple bug. See: http://sourceforge.net/tracker/index.php?func=detail&aid=1280969&group_id=107955&atid=649116 For that reason I don't think it should be made a blocker.
(In reply to comment #5) > This is really an Apple bug. See: (sourceforce tracker URL) I read that already, and I see nothing in that tracker report confirming that it's Apple's bug, except for your insinuation of such in the last comment on it. What evidence do you have that it's Apple's bug?
> What evidence do you have that it's Apple's bug? The evidence is very clear, and is contained in Mark Mentovai's most recent comment (dated 2005-09-04 21:00): The problem occurs (even on OS X 10.4.2) only with Apple's latest version (1.1.0f6) of its AppleUSBTrackpad driver. It doesn't occur with earlier versions (1.0.0f2 and 1.0.1f3) on OS X 10.3.X, or even (using 1.0.1f3) on OS X 10.4.2. The JEP contains _many_ workarounds for Apple bugs (they're scattered all over the JEP's source code) -- so the fact that something is caused by an Apple bug (or design flaw) hasn't stopped me "fixing" it (i.e. working around it) in the past. But I don't happen to own the equipment that I need to reproduce this bug, and I'm not willing to buy a new Apple laptop just to be able to work around it. Apple may already have fixed this problem in its developer seeds of OS X 10.4.3. I have access to them, but don't have the "right" kind of laptop to test them on. Do you have access to the OS X 10.4.3 developer seeds? If so, please install the most recent one on your laptop, and see if it resolves this issue.
Josh, can you weigh in on this? I don't think we're going to block on this unless you have some more compelling reason than what's here now.
Flags: blocking1.8rc1? → blocking1.8rc1-
*** Bug 313194 has been marked as a duplicate of this bug. ***
*** Bug 313518 has been marked as a duplicate of this bug. ***
I've tested this with the final 10.4.3 and Firefox 1.5b2 on my PowerBook G4 with scrolling trackpad, and the problem still occurs despite a new version of the trackpad driver included in 10.4.3 (1.3.0f1). It's probably an Apple bug, but it seems like one that should be worked around before 1.5 release, as this trackpad is shipped with ALL current Mac laptops and this happens on ANY page with a Java applet. It annoys me so much I turned off Java in Firefox and am mostly using Camino at this point (which doesn't experience the problem as it uses Cocoa).
*** Bug 315042 has been marked as a duplicate of this bug. ***
*** Bug 315108 has been marked as a duplicate of this bug. ***
This looks to be a fairly significant and widespread bug, given the number of dupes. Any way a workaround could be implemented for 1.5? As is, Firefox may be considered unusable for users of current PowerBook and iBook models (as two-finger scrolling is a commonly-used function expected to work in all apps).
*** Bug 313527 has been marked as a duplicate of this bug. ***
Since it looks like this won't be fixed for 1.5, could somebody mention this issue in the 1.5 release notes and give instructions on how this can be worked around (disabling JEP, downgrading the trackpad driver, disabling Java)? Also, has anyone attempted to contact Apple about this?
> Since it looks like this won't be fixed for 1.5 Correct. And I now have other claims on my time for the next couple of months. So even if I had the "right" kind of laptop, I wouldn't be able to deal with this problem before the Firefox 1.5 release version comes out. > Also, has anyone attempted to contact Apple about this? I haven't, because (not having susceptible equipment) I wouldn't be able to do any of the tests the Apple people might ask me to do. It'd probably be best for a Mozilla.org person who does have the "right" kind of laptop to open a bug with Apple. Mark? :-) > how this can be worked around Mark Mentovai, in one of his comments at http://sourceforge.net/tracker/index.php?func=detail&aid=1280969&group_id=107955&atid=649116, mentions that SideTrack 1.2.1 gets rid of this problem. SideTrack is a "replacement driver for Apple PowerBook and iBook trackpads" (http://www.ragingmenace.com/software/sidetrack/). If you (Tim) would like to be helpful, please try out SideTrack. If it works out, please write simple, step-by-step instructions on how to install it. Also add any special considerations one needs to be aware of. Post them here when you're done. SideTrack isn't free. But it's very cheap -- only $15.00.
The one issue with SideTrack is that it's type of scrolling is different from Apple's trackpad driver - you use your finger on the edges, rather than using two fingers. Also, as you said, it's not free (although I think it's shareware). Also, using the driver from 10.3.9 does resolve the problem, although this involves more technical work (as I had to download the 10.3.9 update, extract the AppleUSBTopCase.kext file from this, and extract the AppleUSBTrackpad file from inside this and replace the one inside the Tiger AppleUSBTopCase.kext - quite a bit of system surgery). One thing to note is none of these solutions work on the latest 15/17 inch PowerBooks.
> Also, using the driver from 10.3.9 does resolve the problem, No-one outside Apple would be able to legally distribute a separate copy of this driver ... and (as you've found out) extracting a copy from the OS X 10.3.9 update is probably beyond the abilities of most Firefox users. So I don't think this is an option. But if you're willing to write simple, step-by-step instructions, Mozilla.org might be willing to use them :-) There may also be technical issues with using the OS X 10.3.9 driver on OS X 10.4.X (though I'm not aware of any). > One thing to note is none of these solutions work on the latest 15/17 inch > PowerBooks. You mean neither SideTrack nor the 10.3.9 driver work?
On the really new PowerBooks, I believe it is the case that neither SideTrack nor the 10.3.9 driver works since the trackpad is different (I know SideTrack doesn't work for sure, as it says on their homepage). However, I have an older PowerBook - so I haven't tried it.
Also, in trying the 10.3.9 driver, the scrolling was blazingly fast on my system - although on 10.4.3, it was already way too fast (see bug #314856 for more details on this). So I guess there is no real good workaround at this time that works universally, other than perhaps disabling JEP (although then there is still the issue of fast scrolling to contend with).
Do you (Tim) think Danny Bloemendaal's laptop is one of "the latest 15/17 inch PowerBooks"? (See comment #2.) If so, then we know that they're effected by the broken autoscrolling problem. Otherwise, it's possible that they aren't. (I just checked all the other reports that have been duped to this one. Most simply give no details about their computers. But none (besides this one) seem to refer to "the latest 15/17 inch PowerBook".) If Danny is reading this message, please chime in.
His PowerBook can't be one of these new 15/17 inch models, since they were released in October and his report is from September. As far as the "latest 15/17 inch PowerBook models" , all I was saying is that SideTrack doesn't work with these models, and since the trackpad is slightly different they may not be vulnerable. I have no experience with these machines personally, though (I have a 12 inch purchased 4-5 months ago). One idea for a workaround - maybe a simple option (a checkbox, perhaps) could be added to Firefox's preferences to disable the JEP? This would allow both scrolling and Java to work on these machines, albeit the older Java. Also, SideTracck could be suggested for all but the October 15/17 inch models (which aren't compatible with it).
> disabling JEP Probably the best way to do this is to disable Java. It's certainly the simplest. There are _many_ problems with using Java 1.3.1 on the Mac. I suspect they outweigh even the broken autoscrolling problem.
OK - I guess it would be best to suggest in the release notes that users affected by the scroll problem either disable Java or install SideTrack (SideTrack's install is pretty easy - just run the installer and follow the instructions, then you can customize it in the System Preferences). Also, it would be good if somebody with some push could contact Apple about this broken driver and see if they could fix it.
I'm a little bit ambivalent about running to Apple with flailing arms without a more solid understanding of the problem when there are so many private APIs and workarounds at play. (Also, I've only done limited poking around inside the JEP itself.)
It all boils down to whether or not Apple is willing to do anything about a bug that (possibly) only effects the Java Embedding Plugin. But the Java Embedding Plugin is now bundled with Firefox ... which certainly increases its importance to Apple. (See bug 308549 for a somewhat related discussion.) I'd say that "we" ... i.e. Mark :-) ... should open a bug report with Apple. Then we can tell Chris McAfee about it, and possibly also other contacts inside Apple. Apple may choose to ignore the problem, but we'll have done our best.
I just tried SideTrack, and it doesn't seem like a recommendable option to me. My trackpad kept freezing (the cursor wouldn't move) every 20-30 seconds for a couple seconds with the SideTrack driver installed. I guess we can only recommend users disable Java if they want scrolling to work (they can also use Camino, which doesn't experience this problem - but although it's a Mozilla browser, it's not Firefox).
I can confirm this bug with Firefox 1.5 RC2 on my iBook G4 12" (May 2004), MacOS 10.4.3, and just released J2SE 5.0 (JVM 1.5.0_05) (yes, I selected it as the default one in the new Java preferences). My iBook doesn't have native trackpad scrolling: I have it thanks to the iScroll2 driver, and it stops working on all tabs in a Firefox window when I visit a page containing a Java applet. Two details, though: 1. while trackpad scrolling stops working, autoscroll continues happily working here (by pressing the middle button of an external USB mouse... I do not know of any way to activate autoscroll with the trackpad); 2. restarting the browser is not necessary, you can just open a new window and browse in there, scrolling will work fine.
> My iBook doesn't have native trackpad scrolling: I have it thanks to the > iScroll2 driver, and it stops working on all tabs in a Firefox window when I > visit a page containing a Java applet. Interesting. iScroll2 seems to have two parts -- a kernel extension (based on Apple's AppleADBMouse driver) called iScroll2.kext (installed in /System/Library/Extensions/), and a daemon (installed in /usr/local/bin/) called iScroll2Daemon. I wonder if killing the daemon and restarting Firefox would make the problem go away. To kill the daemon, open a Terminal session and enter the following command (you'll be asked for your admin password): sudo killall iScroll2Daemon (I admit that this is pretty unlikely, but it's easy to try. To restore normal behavior (i.e. to restart the daemon), just restart your computer.)
Hi Steven, I issued "sudo killall iScroll2Daemon" in Terminal and checked that the process was actually killed. Then closed Firefox, restarted it, and two-finger scrolling was working fine. I then loaded a page containing a Java applet, and two-finger scrolling stopped working as usual, no difference.
*** Bug 317704 has been marked as a duplicate of this bug. ***
Depends on: 319078
This will be fixed by bug 319078 (this bug is now marked as dependent). See http://developer.apple.com/qa/qa2005/qa1453.html . JEP/Java is installing a kEventMouseScroll Carbon event handler on the window. The handler is called when a non-notchy mouse wheel is moved (touchpads and Mighty Mice) and is consuming the event. The toolbox won't issue kEventMouseWheelMoved events when kEventMouseScroll events are consumed. The event handler is not disposed when the applet disappears. This is not a leak, the standard CE model allows handlers to remain installed indefinitely and are automatically disposed when the event target (window in this case) disappears. This is why the present symptoms are "tainting" all tabs in any window that had hosted an applet. Reverting to the trackpad drivers that shipped with Panther alleviates this problem because those drivers don't supply the fine-grained deltas intended to be used for pixel scrolling, therefore, there are no kEventMouseScroll events. I'll develop a fix in bug 319078. I have already shown in a demo that installing a handler for the new event will get us over this hurdle.
Assignee: joshmoz → mark
Component: General → Widget: Mac
Flags: blocking1.8.0.1?
Keywords: regression
Product: Firefox → Core
Summary: Autoscroll/scrollwheel doesn't work when an java applet is displayed → Scrollwheel doesn't work when an java applet is displayed
Version: unspecified → 1.8 Branch
(Copy of comment also made at http://sourceforge.net/tracker/index.php?func=detail&aid=1280969&group_id=107955&atid=649116.) Thanks for letting me know. And I'm very glad to hear that a solution to this problem may be at hand. But I wonder if I'll need to make HandleDispatcher() (in Handlers.m) handle kEventMouseScroll events, in addition to the kEventMouseWheelMoved events it already handles. Among other things, HandleDispatcher() works around the fact that (by default) the Carbon handlers installed by Apple's Cocoa-Carbon interface swallow all mouse and keyboard events (not allowing them through to a Carbon browser like Firefox). So what it does to "handle" kEventMouseWheelMoved events (for example) is to hook them before the Cocoa-Carbon interface handlers see them, and then (if need be) use SendEventToEventTargetWithOptions() and PostEventToQueue() to ensure that Firefox _does_ get these events. My hunch is that, without my intervention (i.e. unless I make HandleDispatcher() handle kEventMouseScroll events), Apple's Cocoa-Carbon interface handlers will swallow these events -- thereby making the OS think that they've been "consumed".
I considered sending synthetic kEventMouseWheelMoved events as we do in cocoa widgets in order to avoid breaking plugins expecting that event. I'd want to set a parameter marking it as faked-up. With that, though, I'd still worry that this could cause bad effects with plug-ins that understand both kEventMouseScroll and kEventMouseWheelMoved but not the marker param. I'd hope that there aren't any yet, allowing me the opportunity to set precedent right now. It's a bad situation all around. I'll see if and how WebKit handles this tomorrow.
Actually, I should probably just return eventNotHandledErr for wheel events I can't do anything about instead of consuming them all.
Oh, right, that would be, um, incomplete. (But it should still be done.)
*** Bug 319502 has been marked as a duplicate of this bug. ***
I've posted (at bug 319078) a patch to the JavaEmbeddingPlugin.bundle component of the Java Embedding Plugin that might fix this problem (bug 309344): https://bugzilla.mozilla.org/show_bug.cgi?id=319078#c5 To test this patch, you'll need to be able to build JavaEmbeddingPlugin.bundle. Also, once you've built a patched JavaEmbeddingPlugin.bundle, you'll need to do the following (I'll assume that you're working with the current version (0.9.5+b) of the Java Embedding Plugin): 1) Install JEP 0.9.5+b to /Library/Internet Plug-Ins/, following the instructions at http://javaplugin.sourceforge.net/ 2) Remove MRJPlugin.plugin and JavaEmbeddingPlugin.bundle from the Contents/MacOS/plugins subdirectory of your Firefox or SeaMonkey distro. 3) Copy your newly built JavaEmbeddingPlugin.bundle to /Library/Internet Plug-Ins/, overwriting the copy you installed from the JEP 0.9.5+b distro.
I have tested Steven's JEP patch on a Powerbook G4 running OS X 10.4.3 with Firefox 1.5. It looks like it works OK with no obvious side effects.
Glad to hear it! Please keep testing, and let me know if any side effects turn up. (You can (of course) distinguish between patch-side-effects and ordinary bugs by comparing the results from patched 0.9.5+b and "original" 0.9.5+b.) I should be getting a Mighty Mouse in the next few days. With luck, I'll be able to use that to reproduce this problem myself, and test my own patch.
(In reply to comment #41) Here is one regression issues: With the new Java embedding plugin, the Java applet is now getting all the mouse wheel events when the mouse is over the applet. But if the mouse wheel hes been used to scroll the window the applet no longer received the scroll wheel events. Look at http://www.loria.fr/~scheuer/SCPLS/Java/applet.html. If you click in this applet the little arrow will follow the mouse. While it is following the mouse, moving the wheel should change its rotation. Sometimes the arrow will rotate sometimes not. Fortunately this issue also happens with 'real' mouse wheels.
> Sometimes the arrow will rotate sometimes not. Fortunately this issue also > happens with 'real' mouse wheels. I suspect this may be due to problems with the applet itself. And in any case (I think) this is unrelated to bug 309344.
*** Bug 321974 has been marked as a duplicate of this bug. ***
This fixes the bug by always reflowing in nsMenuFrame::OpenMenuInternal(TRUE) before calling nsMenuFrame::ActivateMenu(TRUE), whether it needs it or not. For reference only. The next patch is probably better.
Comment on attachment 207259 [details] [diff] [review] Always reflow when opening the menu (for reference only) Oops, not intended for this bug.
Attachment #207259 - Attachment is obsolete: true
Over to Steven, since the fix will need to be incorporated into the JEP. See attachment 205493 [details] [diff] [review] and the discussion at bug 319078 comment 5 et seq.
Assignee: mark → smichaud
per comment 47 if this requires a new JEP it's not blocking 1.8.0.1 (should a fixed JEP show up there will be an "Add new JEP" bug, and *that* one could block)
Flags: blocking1.8.0.1? → blocking1.8.0.1-
I've just released a new version of the Java Embedding Plugin (0.9.5+c) that resolves this issue: http://javaplugin.sourceforge.net/ To test the fix you'll need to follow the instructions in the JEP's Readme to install the two parts of the JEP to your /Library/Internet Plug-Ins/ directory. But you'll also need to remove the old copy of the JEP that's bundled with your browser (e.g. Firefox 1.5). To do this, delete the following two files from the Contents/MacOS/plugins/ directory of your copy of your Mozilla.org Carbon-based browser: JavaEmbeddingPlugin.bundle MRJPlugin.plugin With luck, the new JEP version will soon be bundled with future versions of the Mozilla.org browsers, and will be avaiable as an update to Firefox 1.5. But those who want the fix sooner will need to do a manual install (as per the instructions I've just given).
(In reply to comment #49) > I've just released a new version of the Java Embedding Plugin (0.9.5+c) that > resolves this issue: Thanks Steven, from a first test I can say the problem seems to be fixed now. Tested on Firefox 1.5, MacOS 10.4.4.
(In reply to comment #49) > I've just released a new version of the Java Embedding Plugin (0.9.5+c) that > resolves this issue: Thank you. Java now works again with my MightyMouse and with my iBook's trackpad. The scrolling bug has been fixed. Firefox 1.5, MacOSX 10.4.4
*** Bug 328646 has been marked as a duplicate of this bug. ***
This will be fixed in 1.5.0.2. Fixed by checkin of bug 327785. Thank you, Stephen!
Status: NEW → RESOLVED
Closed: 19 years ago
Keywords: fixed1.8.0.2, fixed1.8.1
Resolution: --- → FIXED
Whiteboard: [rft-dl]
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: