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.
- 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.