Bug ID: JDK-4402942 MouseWheelEvent not delevered properly after window loses focus

Type: Bug
Component: client-libs
Sub-Component: java.awt
Affected Version: 1.4.0

Priority: P2
Status: Closed
Resolution: Fixed
OS: windows_nt
CPU: x86

Submitted: 2001-01-09
Updated: 2001-09-13
Resolved: 2001-02-27

Other
1.4.0 betaFixed

To reproduce:
-Startup a Java app w/ a ScrollPane (the SymbolTest demo applet works well)
-move the cursor over the ScrollPane and rotate the mouse wheel to ensure that 
 scrolling takes place
-click on the desktop to take focus away from the Java window
-wheeling over the window while it isn't active still scrolls the ScrollPane
-click on the window to make it active again
-(it sometimes takes another iteration of deactivating/activating the window before the problem occurs)
-wheel while over the ScrollPane.  No scrolling.  Oddly, deactivating the window causes wheel scrolling to work again.

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: merlin FIXED IN: merlin-beta INTEGRATED IN: merlin-beta VERIFIED IN: merlin-beta3

24-08-2004

EVALUATION Sounds like a focus issue? Commit to fix in Merlin (new problem in group driver). eric.hawkes@eng 2001-01-09 Name: rpR10076 Date: 01/26/2001 The problem looks mouse-dependent and mouse-driver dependent. I tried it on two machines with different results. First machine has Genius PS/2 Netscroll+ mouse and Genius drivers installed. On this machine mouse wheel scrolling works perfectly. Second machine has Microsoft serial mouse which is auto-recognized by the system. On this machine mouse wheel scrolling doesn't work when the window is active. ###@###.### 01/21/01 ====================================================================== Name: rpR10076 Date: 02/06/2001 02/05/01 ###@###.### I installed Microsoft IntelliMouse 3.2 and now I can reproduce the bug exactly as it is described. The following difference with NetScroll+ software was discovered: NetScroll+ soft doesn't generate mouse wheel events, but instead produces scroll events. So when the mentioned test (SymbolTest demo) is running, ScrollPane's processMouseWheelEvent isn't called at all. With IntelliMouse it is called and the bug can be reproduced. ====================================================================== Name: rpR10076 Date: 02/12/2001 ###@###.### Jan 12 2001 After performing some minimization, the following became obvious: before this behaviour became broken (it still worked in build b35 where focus changes were introduced) the canvas that is inside the scrollpane received focus every time we clicked into it. Currently it only receives focus first time we click nito it, and after deactivation/activation the canvas no longer receives focus, and mouse wheel events are not delivered. This is clearly a regression, and I am still investigating the putbacks that happened approximately at the time it was introduced. Another question, however, is whether canvas should receive the focus at all. ====================================================================== Name: rpR10076 Date: 02/12/2001 ###@###.### Feb 12 2001 This was introduced with the putback of 4380809 (Dec 1, 2000). It works without the changes made to fix this bug. ====================================================================== Name: osR10079 Date: 02/13/2001 The problem is as follows: in fix for 4380809 i added sm_focusedWindow to track window which should be focused in Java-sense. And if sm_focusedWindow is NULL i do not call handlers for WM_(SET/KILL)FOCUS. In these changes i assumed that window receives WM_KILLFOCUS before WM_ACTIVATE, but this behaviour is not specified and looks like we can not rely on this. As result, we don't handle WM_KILLFOCUS and don't reset sm_focusOwner to NULL because sm_focusedWindow is already NULL. But after that when we call AwtSetFocus to set focus on the same component which has focus before deactivation, we find out that sm_focusOwner is already set to this window and do nothing. So, we have no focus owner and do not receive mouse wheel events for this reason. So, to fix this problem, i suggest to handle WM_KILLFOCUS independently from sm_focusedWindow. This change doesn't break fix for 4380809. The code that prevents calling WM_KILLFOCUS when sm_focusedWindow is NULL was added to fix for 4380809 only to make handling of WM_KILLFOCUS similar to WM_SETFOCUS, but, as practice shows, it was a mistake. ###@###.### 13 Feb 2001 ======================================================================

24-08-2004

SUGGESTED FIX Name: osR10079 Date: 02/25/2001 ###@###.### 26 Feb 2001 *** C:\TEMP\geta232 Tue Feb 13 12:15:14 2001 --- awt_Component.cpp Tue Feb 13 12:15:14 2001 *************** *** 969,977 **** ? WmSetFocus((HWND)wParam) : mrConsume; break; case WM_KILLFOCUS: ! mr = (!sm_suppressFocusAndActivation && (sm_focusedWindow != NULL)) ! ? WmKillFocus((HWND)wParam) : mrConsume; ! break; case WM_ACTIVATE: if (!sm_suppressFocusAndActivation && (!(BOOL)HIWORD(wParam) || (LOWORD(wParam) == WA_INACTIVE))) --- 969,984 ---- ? WmSetFocus((HWND)wParam) : mrConsume; break; case WM_KILLFOCUS: ! /* ! * We should process WM_KILLFOCUS independently from ! * sm_focusedWindow. Because when we deactivate window, ! * we receive WM_ACTIVATE(WA_INACTIVE) before WM_KILLFOCUS, ! * and sm_focusedWindow always will be NULL here in this case. ! * Fix for 4402942 by ###@###.### ! */ ! mr = (!sm_suppressFocusAndActivation) ! ? WmKillFocus((HWND)wParam) : mrConsume; ! break; case WM_ACTIVATE: if (!sm_suppressFocusAndActivation && (!(BOOL)HIWORD(wParam) || (LOWORD(wParam) == WA_INACTIVE))) ======================================================================

24-08-2004