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.
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.
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).
This is a regression of 6903034. For some reason the procedure of taking the screenshot from the composite overlay window doesn't work reliably.
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