+1 from me.
-phil
On 4/19/20, 7:07 AM, Sergey Bylokhov wrote:
On 4/13/20 11:21 pm, Sergey Bylokhov wrote:
Looks like a few tests for menu mnemonics started to fail
intermittently after this fix, I will double-check the root cause.
Had to spend some time analyzing the new test failures, here is a new
webrev, see comments:
http://cr.openjdk.java.net/~serb/8242174/webrev.01
In the CRobot.m the new changes are just the small cleanup
- gNextKeyEventTime is initialized to zero
- CGEventPost now use "kCGHIDEventTap" which aligned to the new
"kCGEventSourceStateHIDSystemState"
The "/RealSync/Test.java" was removed from the problem list as it now
passed, checked in mach5 lots of times.
The test/jdk/ProblemList.txt was updated due to different reasons. The
fix itself make the robot more stable,
lots of tests which previously were unstable due to robot now always
passed. But there are a few tests which
started to fail:
- java/awt/TrayIcon/ActionEventTest/ActionEventTest.java: the test
does not check that the robot actually
clicks on the tray icon, So it is always passed on macOS due to a
bug in the robot, and after the fix
when the robot actually started to click on the tray icon the test
started to fail, filed:
https://bugs.openjdk.java.net/browse/JDK-8242801
- java/awt/keyboard/AllKeyCode/AllKeyCode.java; The test presses the
"help" button which starts the
"macOS subsystem machinery", which changes the cursor, ignores all
key presses and waits for the
first mouse click on the component for which the help should be
provided, and this broke the tests
executed later, filed
https://bugs.openjdk.java.net/browse/JDK-8242930
On 4/13/20 8:09 am, Sergey Bylokhov wrote:
Hello.
Please review the fix for jdk/client.
Bug: https://bugs.openjdk.java.net/browse/JDK-8242174
Fix: http://cr.openjdk.java.net/~serb/8242174/webrev.00
This is part of the effort to stabilize the execution of our nightly
tests. We already fix most of the
issues in the tests which made the OS and other tests unstable for
some reasons.
And this is attempt to fix the "product" bug. I have found that some
of our tests, like
"java/awt/Dialog/NestedDialogs/Modeless/NestedModelessDialogTest.java"
have the code like this:
robot.keyPress(KeyEvent.VK_SHIFT);
robot.keyPress(KeyEvent.VK_H);
robot.waitForIdle();
robot.keyRelease(KeyEvent.VK_H);
robot.keyRelease(KeyEvent.VK_SHIFT);
This should work fine, but unfortunately on macOS, such code
produces "random" strange
results, sometimes some keys are pressed but never released,
sometimes the shift
modifier is disappeared and so on. The situation is quite bad
because the test itself is
passed but leaves the modifier key pressed, this occurred in
different tests and caused
to fail some other tests around.
Note that our code is implemented according to the official Apple's
documentation, so I had
filed a bug to Apple:
https://bugs.openjdk.java.net/browse/JDK-8242174?focusedCommentId=14328518&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14328518
So in this fix, I tried to follow the recommendation above. For all
events(except mouse move)
an additional delay(50 ms) is added. If the test already uses some
delay then the biggest
one will be used(the new delay will not be added to the old one)
This new delay will solve the problem of events lost, but it does
not fix the problem of disappeared
modifiers(SHIFT/CTRL, etc). I tried different solutions and finally
was able to find one suggestion
which works fine, is to use
CGEventSourceCreate(kCGEventSourceStateHIDSystemState); instead of
NULL in our events:
https://developer.apple.com/documentation/coregraphics/cgeventsourcestateid/kcgeventsourcestatehidsystemstate?language=objc
