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.
EVALUATION
Despite the fcat that this test is intended to verify some windows-specific
behavior, it acts in the limits of publicly available API, and therefore, it
should be handled properly by the AWT Robot.
I do believe that any multi-frame application will suffer from the same problem
too. So, it seems to be incorrect to request any modification of existing
regression test just to hide a problem in the robot component.
Note also that the problem is triggered by recent enhancement in a logic
of linux/unix implementation of the AWT Robot (this test woks fine on OEL5
until b138) so this issue should be addressed on the side of the robot.
05-05-2011
EVALUATION
This is a platform-specific test, and as such it should verify that the AWT Toolkit corresponds to the Windows platform (e.g. the class name could be checked to contain the WToolkit string).
05-05-2011
EVALUATION
This is a regression of 6903034. For some reason the procedure of taking the screenshot from the composite overlay window doesn't work reliably.
05-05-2011
EVALUATION
This test uses awt robot to capture results of rendering. Observed failure is
a manifestation of some robot issue which is likely introduced by the fix for
CR 6903034. Note that captured images are completely wrong: they contains solid
gray color whereas actual frame content is a black rectangle on a red background.
This test can be run in debugging mode, in order to save captured images:
java GdiDDSyncTest -savecapture -show
So, I am re-dispathing this CR to awt team to investigate actual reason of the
robot failure.