RFR: 8288415: java/awt/PopupMenu/PopupMenuLocation.java is unstable in MacOS machines [v2]
Sergey Bylokhov
serb at openjdk.org
Wed Jun 29 00:56:53 UTC 2022
On Fri, 17 Jun 2022 10:57:59 GMT, Manukumar V S <mvs at openjdk.org> wrote:
>> java/awt/PopupMenu/PopupMenuLocation.java seems to be unstable in MacOS machines, especially in MacOSX 12 machines. It seems to be a testbug as adding some stability improvements fix the issue. It intermittently fails in CI causing some noise. This test was already problem listed in windows due to an umbrella bug JDK-8238720. I have removed the problem listing and tested it in windows platform also, it works fine there.
>>
>> Fix:
>> Some stability improvements have been done and the test has been run 100 times per platform in mach5 and got full PASS.
>
> Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:
>
> Review comments fixed: Removed -Dsun.java2d.uiScale=1, frame.getLocationOnScreen() removed from EDT, added volatile keyword for actionEventReceivedLatch
test/jdk/java/awt/PopupMenu/PopupMenuLocation.java line 69:
> 67: GraphicsConfiguration gc = sd.getDefaultConfiguration();
> 68: Rectangle bounds = gc.getBounds();
> 69: Point point = new Point(bounds.x + 20, bounds.y + 20);
Why do you need to add this additional 20 pixels? When we click on the frame we already shift the mouse click location by 130 pixels from the top of the frame.
test/jdk/java/awt/PopupMenu/PopupMenuLocation.java line 119:
> 117: private static void openPopup(final Frame frame) throws Exception {
> 118: robot.waitForIdle();
> 119: Point loc = frame.getLocationOnScreen();
Since you removed the reading the location from EDT via a separate loc variable, you do not need to rename pt here? The only meaningful change is adding the CountDownLatch?
-------------
PR: https://git.openjdk.org/jdk/pull/9187
More information about the client-libs-dev
mailing list