8356061: [macos] com/apple/laf/RootPane/RootPaneDefaultButtonTest.java test fails on macosx-aarch64 machine #25244
Conversation
Merge openjdk/jdk into mickleness/jdk
Merge openjdk/jdk
Merge from openjdk/jdk
Updating mickleness/jdk from openjdk/jdk
updating to openjdk/jdk
I could reproduce failures with this test if I changed every call to Robot.delay to 1ms. (I could not reproduce failures from the master branch on my machine.) I'm increasing the delay before we start capturing pixels from 100ms to 1000ms.
This may be a red herring, but I think it's weird that the test failed because it spotted instances of the color 0x373737. I don't know exactly where that would appear in the test app's UI.
|
👋 Welcome back mickleness! A progress list of the required criteria for merging this PR into |
|
❗ This change is not yet ready to be integrated. |
|
@mickleness The following label will be automatically applied to this pull request:
When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command. |
Webrevs
|
| @@ -128,7 +128,7 @@ private static void test(Robot robot, AbstractButton buttonToClick, | |||
| robot.delay(20); | |||
| robot.mouseRelease(InputEvent.BUTTON1_DOWN_MASK); | |||
|
|
|||
| robot.delay(100); | |||
| robot.delay(1000); | |||
There was a problem hiding this comment.
it will be useful to add the same delay before the first call to test, right after invokeAndWait.....setVisible(...)
Also please move creation and access_to all Swing components to EDT(button, radioButton1)
There was a problem hiding this comment.
I added an additional delay. I'm not sure exactly what refactor you're looking for, but I rewrote the test to put more in the EDT.
(I double-checked that the test still passes, but that doesn't prove much since I've never reproduced a failure.)
I did try at one point blocking the testing thread until the EDT had a chance to complete an invokeLater runnable, but that didn't seem to make a difference so I didn't commit it.
This was requested here: openjdk#25244 (comment) So now we'll pause at least 1.1s before the first call to `jc.getLocationOnScreen`, and at least 2.1s before the first call to `robot.getPixelColor(x, y)`. (getLocationOnScreen has never failed with an IllegalStateException.)
This was requested here: openjdk#25244 (comment) mrserb asked: "Also please move creation and access_to all Swing components to EDT" (I'm not sure this will help much? My understanding was *creation* of Swing components could happen off the EDT as long as they were made displayable on the EDT.) Now we still call jc.getLocationOnScreen off the EDT. If that posed a thread-based problem it'd probably manifest as a IllegalComponentStateException, which is not mentioned in 8356061.
Unfortunately I'm unable to reproduce this failure. I slowed the test down; it passes on my machine before and after this PR.
I added a little bit of logging that might also help identify what's happening.
Does anyone have any more suggestions?
Progress
Issue
Reviewing
Using
gitCheckout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/25244/head:pull/25244$ git checkout pull/25244Update a local copy of the PR:
$ git checkout pull/25244$ git pull https://git.openjdk.org/jdk.git pull/25244/headUsing Skara CLI tools
Checkout this PR locally:
$ git pr checkout 25244View PR using the GUI difftool:
$ git pr show -t 25244Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/25244.diff
Using Webrev
Link to Webrev Comment