User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; nl; rv:1.9.1b99) Gecko/20090605 Firefox/3.5b99 (.NET CLR 3.5.30729) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; nl; rv:1.9.1b99) Gecko/20090605 Firefox/3.5b99 (.NET CLR 3.5.30729) When Java Applet in iframe from pluraserver is used on a website, then the use of the wheel on the mouse is blocked, until the user clicks into the window. Probably (speculation), lost focus. I consider a bugn that must be fixed, because use of wheel on mouse is common use. It irritates when it does not work. It reproduces both on 3.0 and 3.5b99 Reproducible: Always Steps to Reproduce: 1. Go to specified site. 2. Go to forum 3. When pluraserver things loads, wheel on mouse won't work until user clicks on screen. Actual Results: Wheel on mouse blocked. Expected Results: Wheel on mouse still working (as in Safari, IE and Chrome).

This file reproduces on my computer the problem.

This problem is not limited to this applet. If we click the applet, we can't scroll the mozilla window until we click outside tha applet again.

I couldn't find a way to fix this without hooks. Please teach me if someone know a better idea.

So this prevents dispatching of WM_MOUSEWHEEL events into the plugin? Is that really what we want? Could you do this in PluginWndProc in nsPluginNativeWindowWin instead? It seems to me that this bug is not a regression, but the way we've always behaved, is that right?

If we are going to do this, we should have an automated test for it. You can extend the test patch in bug 520462 to let nsWindow::SynthesizeNativeMouseEvent simulate mousewheel events.

(In reply to comment #4) > So this prevents dispatching of WM_MOUSEWHEEL events into the plugin? Is that > really what we want? At present, wheel events will be dispatched as follows: (1) plugin has focus, cursor is on the plugin -> to plugin (2) plugin has focus, cursor is on us -> to plugin (3) we have focus, cursor is on the plugin -> to plugin (4) we have focus, cursor is on us -> to us This patch will change the behavior of case (2). I think it's more reasonable. > Could you do this in PluginWndProc in nsPluginNativeWindowWin instead? It is not possible because some plugins (including Java) will create their own window. So our window will not receive the event at all. > It seems to me that this bug is not a regression, but the way we've always > behaved, is that right? Our behavior was inconsistent between windowed and windowless plugins. This patch will make the behavior consistent. (In reply to comment #5) > If we are going to do this, we should have an automated test for it. You can > extend the test patch in bug 520462 to let nsWindow::SynthesizeNativeMouseEvent > simulate mousewheel events. Will do.

Also, I'm planning to make widgets wheel-transaction aware to fix bug 483136. It will require this fix.

> + // aWnd will be NULL if the child window belongs to non-Mozilla thread. > + // (e.g. Java applet) > + if (!aWnd) { > + hWheelHook = ::SetWindowsHookEx(WH_MOUSE_LL, WheelHookProcLL, > + nsToolkit::mDllInstance, 0); > + return; > + } Does this work on static build? > + if (nCode == HC_ACTION && > + (wParam == WM_MOUSEWHEEL || wParam == WM_MOUSEHWHEEL)) { Don't you need to check the WM_*SCROLL of Thinkpad?

(In reply to comment #7) Curious if this code would cover or change trackpad behavior or if you have a bug for those issues. If I use the trackpad scroller on my Compaq laptop on XP, The trackpad scrolling behavior is also flaky, sometimes it scrolls fine, sometimes I get the scrollbar cursor but doesn't allow me to scroll.

(In reply to comment #6) > (In reply to comment #4) > > So this prevents dispatching of WM_MOUSEWHEEL events into the plugin? Is that > > really what we want? > At present, wheel events will be dispatched as follows: > (1) plugin has focus, cursor is on the plugin -> to plugin > (2) plugin has focus, cursor is on us -> to plugin > (3) we have focus, cursor is on the plugin -> to plugin > (4) we have focus, cursor is on us -> to us > This patch will change the behavior of case (2). I think it's more reasonable. Windows explicitly sends WM_MOUSEWHEEL events to the focused window. http://msdn.microsoft.com/en-us/library/ms645617%28VS.85%29.aspx So it may be that Microsoft intends wheel events to go to the focused content. However, I think wheel events going to the content under the cursor is more useful and probably what users want, so I'm OK with this change. But let's consult Beltzner.

(In reply to comment #10) > However, I think wheel events going to the content under the cursor is more > useful and probably what users want, so I'm OK with this change. It's also what we currently do for Web content other than plugins.

(In reply to comment #8) > Does this work on static build? Yes. Unlike other global hooks, WH_MOUSE_LL doesn't inject DLLs. > > + if (nCode == HC_ACTION && > > + (wParam == WM_MOUSEWHEEL || wParam == WM_MOUSEHWHEEL)) { > Don't you need to check the WM_*SCROLL of Thinkpad? Unfortunately we can't because WH_MOUSE hook looks only mouse messages. However this patch will not break Thinkpad driver. It only fails to redirect the messeges to us. I don't think it's worth adding yet another workaround for them. Synaptics should fix the driver in the first place.

(In reply to comment #12) > However this patch will not break Thinkpad driver. It only fails to redirect > the messeges to us. I don't think it's worth adding yet another workaround for > them. Ah, right. Thanks.

Note. There is a similar problem with keyboard shortcuts. If you are browsing in Private mode, going back to normal mode doesn't always work. Sometimes you have to click in the window, before you can return. Lucas

(In reply to comment #14) > Note. > > There is a similar problem with keyboard shortcuts. If you are browsing in > Private mode, going back to normal mode doesn't always work. Sometimes you have > to click in the window, before you can return. > > Lucas That sounds like bug 78414, though if Private Browsing is affected, it may be a separate bug altogether.

java latest update doesn't give focus to java if you point it,you can scroll even if you focus the java box

The HTML <applet> element and related java functionality was removed from Gecko in Bug 1279218. Marking related bugs as invalid.