JDK-6986252 : java/awt/Focus/ConsumeNextKeyTypedOnModalShowTest/ConsumeNextKeyTypedOnModalShowTest.java faled
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 7,8u25,11
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • OS: generic
  • CPU: generic
  • Submitted: 2010-09-21
  • Updated: 2023-10-09
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.
Other
tbdUnresolved
Related Reports
Relates :  
Description
see comments

Comments
Test fails on mac 10.13.3 during test sprint run
27-02-2018

- this is an issue reported against 7(7u), - there are now affected version 9 filed for this issue - 7u issues are transferred to Sustaining Nevertheless if someone have a report against 9 - please reopen and add affectedVersion 9 or 7u specific escalations might be reopen to Sustaining
10-08-2014

- this is an issue reported against 7(7u), - there are now affected version 9 filed for this issue - 7u issues are transferred to Sustaining Nevertheless if someone have a report against 9 - please reopen and add affectedVersion 9 or 7u specific escalations might be reopen to Sustaining
10-08-2014

SUGGESTED FIX diff on ConsumeNextKeyTypedOnModalShowTest.java: if (!Util.trackFocusGained(tf1, action, 3000, false)) { throw new RuntimeException("Test failed: TAB was processed incorrectly!"); } + Util.waitForIdle(robot); // Check for type-ability. robot.keyPress(KeyEvent.VK_A); robot.delay(50);
28-10-2010

EVALUATION The test does following. 1) It generates KeyEvent(TAB) and this also shows up the blocking dialog so the secondary loop get started. 2) wait. 3) Now we post the Runnable and expect the Util.trackFocusEvent(args) returns true someday. // Dispose the dialog. Runnable action = new Runnable() { public void run() { dialog.dispose(); } }; if (!Util.trackFocusGained(tf1, action, 5000, false)) { throw new RuntimeException("Test failed: TAB was processed incorrectly!"); } And it actually does but the dialog *is not* yet disposed by that time. 4) So we type the A and got nothing on the output as it was just been filtered out on the internal pump. Have a look into the Util class: private static boolean trackEvent(int eventID, Component comp, Runnable action, int time, boolean printEvent) { [do some stuff here] listener.listen(comp, printEvent); action.run(); return Util.waitForCondition(listener.getNotifier(), time); } action.run() called on the current thread with run(). That means that the dialog.dispose() may not yet finished by the time we awaken from the trackEvent(args). BTW by that reason playing with the timeout parameter in Util.trackFocusGained(tf1, action, 3000, false)) won't help. This looks like a thread race in the test.
28-10-2010

EVALUATION Reproducible on the submitter's host. I can not reproduce the problem on Windows Vista.
21-09-2010