JDK-6445802 : regreesion test javax/swing/ToolTipManager/4768127/bug4768127.java fails in b90
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 6
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,solaris_10
  • CPU: generic,sparc
  • Submitted: 2006-06-30
  • Updated: 2011-01-19
  • Resolved: 2006-08-18
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 6
6 b96Fixed
Related Reports
Duplicate :  
Relates :  
Relates :  
Relates :  
Description
Java Version: build 1.6.0-rc-b90
PlatWrom: SNBOHMKHJYFMYXO

Problems: 
The regression test fails in b90 promotion build.

Errors as following:

---------System.err:(5/406)----------
java.lang.Error: Extra MouseMotionListeners were added to the label "Label 1" by ToolTipManager
	at bug4768127.destroy(bug4768127.java:86)
	at com.sun.javatest.regtest.AppletWrapper$AppletThread.run(AppletWrapper.java:157)
	at java.lang.Thread.run(Thread.java:619)
STATUS:Failed.Applet thread threw exception: java.lang.Error: Extra MouseMotionListeners were added to the label "Label 1" by ToolTipManager
result: Failed. Execution failed: Applet thread threw exception: java.lang.Error: Extra MouseMotionListeners were added to the label "Label 1" by ToolTipManager


test result: Failed. Execution failed: Applet thread threw exception: java.lang.Error: Extra MouseMotionListeners were added to the label "Label 1" by ToolTipManager

How to reproduce:
1. set up JAVA_HOME to mustang b90
2. run the attached script.

Please see jtr file as attched.

Comments
EVALUATION The test originally written for the bug when ToolTipManager registers itself as a listener each time when mouse is moved over a component and it was the actual memory leak: you could have a lot of dulplicated listeners for a component. Here we have a different situation: before 4398733 was fixed, MouseEvents worked incorrectly if you switch between two internal frames and this fact let this test pass. If you rewrite the test without internal frames it will fail on 1.5 and 1.6 The reason is: when mouse is pressed ToolTipManager nullify the insideComponent field when mouse is moved it restores insideComponent when mouse is exited it remove the listener if insideComponent != null The test use robot.mouseMove() method which instantly moves cursor from one label to another, it moves it so fast that there is no mouseMotion event generated between press and exit, so on MouseExited insideComponent is null and listener is not removed. Conclusion: - This test passed only because the bug in Internal frames - The test with no internal frames fails both on 1.5 and 1.6, so it's not a regression - In the worst case we have only one extra ToolTipManager listener for a component and this is a very rare situation, because it's quite difficult for a human to reproduce this problem in a real application without using java.awt.Robot - I filed the bug P5 6458458 for Dolphin for this little problem - The first suggested fix is not perfect, because when you press on a component, move a mouse's cursor you want to see tooltip again but suggested fix would break it (I added another suggested fix for 6458458) - I fix the test to move mouse more smoothly this solves the problem
09-08-2006

EVALUATION Mike Bronson's invetigation results: The fix for 4398733, which was integrated into b46, changed the way activation of an internal frame is detected. Before that fix, activation was detected by intercepting the button press on the glass pane of an inactive internal frame. After the fix it was detected by an AWTEventListener, and the glass pane was no longer used for detecting activation. Since the glass pane is no longer intercepting the button press, the underlying component in the internal frame is now receiving the button press. In the failing regression test bug4768127.java, the underlying component that is receiving the button press is the JLabel. That button press was being intercepted by the glass pane before the fix for 4398733. This means that ToolTipManager.mousePressed is now being called, when it was not called before the fix for 4398733. Now it appears that this line in initiateToolTip: component.addMouseMotionListener(this); gets called when mouseEntered calls initiateToolTip, and initiateToolTip also sets insideComponent. The fix for 4398733 exposes a bug in ToolTipManager.mousePressed, which is that it is leaking the MouseMotionListener, when it sets insideComponent to null without removing the MouseMotionListener on the component that it references. If you look at the method ToolTipManager.mouseExited, you will see that it does indeed call insideComponent.removeMouseMotionListener before it sets insideComponent to null. The method mousePressed should do the same thing, before it sets insideComponent to null.
04-08-2006

EVALUATION The bug is similar to 4768127: sometimes ToolTipManager does not remove itself from component, registered as MouseMotionListener. But it seems, that there is no any serious regression, because ToolTipManager is added as MouseMotionListener only once. I cannot reproduce the situation when there are two or more ToolTipManagers, registered as MouseMotionListener for a single component. The suggested fix works, but maybe it is possible to find a better solution, if we find the main cause of the problem.
03-08-2006

EVALUATION See Suggested Fix.
01-08-2006

EVALUATION mousePressed method in ToolTipManager.java is doing this: insideComponent = null; but it should be doing this: if (insideComponent != null) { insideComponent.removeMouseMotionListener(this); } insideComponent = null; which explains why the test bug4768127.java is finding extra MouseMotionListeners and failing.
01-08-2006

SUGGESTED FIX src/share/classes/javax/swing/ToolTipManager.java *** 561,566 **** --- 561,569 ---- hideTipWindow(); enterTimer.stop(); showImmediately = false; + if (insideComponent != null) { + insideComponent.removeMouseMotionListener(this); + } insideComponent = null; mouseEvent = null; } ===========================================================================
01-08-2006

EVALUATION Failure started in 1.6.0-ea-b46.
01-08-2006

EVALUATION Not reproducible in 1.6.0-ea-b45.
31-07-2006

EVALUATION Reproducible in 1.6.0-ea-b46.
31-07-2006

EVALUATION Reproducible in 1.6.0-rc-b93.
31-07-2006

EVALUATION I found that this test starts to fail after bug 4398733 was fixed, actually bug 4768127 doesn't start to reproduce (we have only one reference to TooltipManager so it might be not a big problem and fixing test is enough), but the test start to behave differently - TooltipManager mouse listener doesn't get removed like it used to; reassigned to responsible enginieer of bug the #4398733
25-07-2006

EVALUATION This is not a regression, but test started to behave differently I am looking for the reason of that
24-07-2006