JDK-8273573 : [macos12] ActionListenerCalledTwiceTest.java fails on macOS 12
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 11,17,18
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2021-09-09
  • Updated: 2022-06-10
  • Resolved: 2022-06-07
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.

To download the current JDK release, click here.
JDK 19
19 b26Fixed
Related Reports
Relates :  
Description
javax/swing/JMenuItem/ActionListenerCalledTwice/ActionListenerCalledTwiceTest.java is repeatedly failing on macOS 12

https://docs.oracle.com/en/java/javase/11/docs/api/java.desktop/java/awt/Desktop.html#setDefaultMenuBar(javax.swing.JMenuBar)

provides a menu bar that can still be accessed when there are no active frames.
This is using the system menu bar on maOS and was implemented as part of https://openjdk.java.net/jeps/272

The test effectively runs twice  once with the window active and again iconified.
It is the latter which fails because no events are delivered and  we get

Exception in thread "main" java.lang.Exception: DefaultMenuBar Test failed: ActionListener for Item1 called 0 times instead of 1!
    at ActionListenerCalledTwiceTest.testForTwice(ActionListenerCalledTwiceTest.java:114)
    at ActionListenerCalledTwiceTest.main(ActionListenerCalledTwiceTest.java:48)

It appears that in this test when the app is in the iconfied state the test is expecting the keystrokes to go
to this menu bar still. I don't know if the expecation is correct, but this isn't happening and worked in earlier versions of macOS

Also I noticed that the test doesn't exit. It appears that the call to

Desktop.getDesktop().setDefaultMenuBar(bar);

is effectively creating another visible window so the AWT thread doesn't exit.

Adding this line below allows the test to exit and should be added to the test
            SwingUtilities.invokeAndWait(() -> Desktop.getDesktop().setDefaultMenuBar(null));

One thing it I noticed tho' i that the spec of this method doesn't actually say null is allowed ..
It might be a good idea to update it - probably as a separate bug since any fix to this may need
to be backported.

Comments
Changeset: 1499e5ea Author: Alexander Zvegintsev <azvegint@openjdk.org> Date: 2022-06-07 13:57:01 +0000 URL: https://git.openjdk.java.net/jdk/commit/1499e5eac0cad3745495baeda7b5f9157647ebe9
07-06-2022

A pull request was submitted for review. URL: https://git.openjdk.java.net/jdk/pull/9003 Date: 2022-06-02 20:12:01 +0000
02-06-2022

It is reproducible again.
21-12-2021

This affected machine is no longer able to reproduce the issue.
15-12-2021

Not every macOS 12 x64 is affected by this issue. But as for the specific failing macOS 12 x64 machine, reverting CRobot.m to state before JDK-8242174 fix allows to send keyboard and mouse keypress/keyrelease events on it.
09-12-2021

It seems to be a robot/system configuration issue, but a strange one. It was tested on 3 configurations: macOS 12 aarch64, macOS 12 x64 and my laptop macOS 11.6.1 x64. All of them have Terminal.app added and enabled Security & Privacy → Accessibility. Basically it should allow to its child processes to control mouse and keyboard. local macOS 11.6.1 x64: works as expected vnc: macOS 12 aarch64: works as expected vnc: macOS 12 x64 Behaves very strange: mouse is successfully moved, but keyboard and mouse keypress/keyrelease are not delivered. Adding java executable directly in Security & Privacy → Accessibility doesn't change anything. But if you uncheck Terminal.app in Security & Privacy → Accessibility the robot won't even be able to move the mouse.
03-12-2021

The issue is reproducible on macOS12 x64, but not on aarch64.
02-12-2021