JDK-6847958 : MouseWheel event is getting triggered for the disabled Textarea in jdk7 b60 pit build.
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 7
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: linux
  • CPU: generic,sparc
  • Submitted: 2009-06-04
  • Updated: 2011-03-07
  • Resolved: 2011-03-07
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7
7 b66Fixed
Related Reports
Duplicate :  
JDK-6848333 - Reg-test java/awt/Scrollbar/ScrollbarMouseWheelTest/ScrollbarMouseWheelTest.html fails
Duplicate :  
JDK-6806244 - PIT : MouseWheel event get triggered for the disabled Textarea in jdk7 b48 pit build.
Relates :  
JDK-6315717 - Support For Mouse With Multiple Scroll Wheels and 4 or More Buttons
Description
This is same as CR 6806244. The bug was closed as duplicate of 6799099.
The bug 6799099 is been fixed for Jdk7 b60 pit build. But this issue is still seen with Jdk7 b60 pit build.

I reproduced the failure in RHEL5 and Ubuntu with Jdk7 b60 pit build.

Attached is the testcase (HWMouseWheelListenerTest.java)
The testcase fails with the following error:

"FAIL: MouseWheel event occured when mouse wheel scrolled over disabled TextArea
Event occured for source=java.awt.List[list0,175,46,136x72,selected=null]
Test failed!"

Steps to Reproduce:

1) Run the attached testcase 
java -DresultsDir=. HWMouseWheelListenerTest
2) Observe the test results , if you see Test fails , then the bug is reproduced.

Also in Ubuntu , the testcase MousePointerMouseWheelTest.java (attached) fails with Jdk7 b60 pit build with the following error:

"FAIL: The frame did not receive focus when clicked
Test failed!"

The testcase passes in Rhel5

Steps to Reproduce:

1) Run the attached testcase in ubuntu(MousePointerMouseWheelTest.java)
java -DresultsDir=. MousePointerMouseWheelTest
2) Observe the test results , if you see Test fails , then the bug is reproduced.
Comments
SUGGESTED FIX http://sa.sfbay.sun.com/projects/awt_data/7/6847958
08-07-2009
EVALUATION Sounds like a mistake in the fix: nowdays we ignore 4-th and 5-th button handling on XAWT so the grab sequesnce may not be finished. Should check if simple if-statement mentioned in the #1 evaluation entry make sense in the tests perspective. The defect is not specific for a particular component.
08-06-2009
EVALUATION The testcase displayes a frame, the frame contains three components - one text area, one list and one button (the button is the only focus owner during the test). During one of the checks of the test the robot moves the mouse pointer over the list, then it generates the mouse wheel events on the list. It works OK. The next check is to disable the text area and move the mouse pointer over the text area and try to generate the mouse wheel events on the text area. The result of the test is a number of mouse wheel events coming to the list which was the target of previous mouse wheel events. The test doesn't expect to catch any mouse wheel events and fails immediately. The issue is a regression of the changes for 6315717 (Support For Mouse With Multiple Scroll Wheels and 4 or More Buttons). The particular change is below: src/solaris/classes/sun/awt/X11/XBaseWindow.java *** 977,988 **** * Activate automatic grab on first ButtonPress, * deactivate on full mouse release */ public void handleButtonPressRelease(XEvent xev) { XButtonEvent xbe = xev.get_xbutton(); ! final int buttonState = xbe.get_state() & (XConstants.Button1Mask | XConstants.Button2Mask ! | XConstants.Button3Mask | XConstants.Button4Mask | XConstants.Button5Mask); switch (xev.get_type()) { case XConstants.ButtonPress: if (buttonState == 0) { XAwtState.setAutoGrabWindow(this); } --- 977,993 ---- * Activate automatic grab on first ButtonPress, * deactivate on full mouse release */ public void handleButtonPressRelease(XEvent xev) { XButtonEvent xbe = xev.get_xbutton(); ! int buttonState = 0; ! for (int i = 0; i<XToolkit.getNumMouseButtons(); i++){ ! // A bug in WM implementation: extra buttons doesn't have state!=0 as they should on Release message. ! if ((i != 4) && (i != 5)){ ! buttonState |= (xbe.get_state() & XConstants.buttonsMask[i]); ! } ! } switch (xev.get_type()) { case XConstants.ButtonPress: if (buttonState == 0) { XAwtState.setAutoGrabWindow(this); } The value of the button state is accepted only between 1 and 5 buttons. The fix for 6315717 ingores this button mask for fifth button. This logic break the following checks. This modified button mask doesn't pass the next check for the full release and the previous grab is still active (in our case, the list is the active grab) . As a side effect, the list will receive a number of mouse wheel events until the text area becomes the active grab.
08-06-2009