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
--
Best regards, Sergey.
