JDK-8280057 : [macOS] Paste event triggered twice from accelerator in system menubar and text input control
  • Type: Bug
  • Component: javafx
  • Sub-Component: controls
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • Submitted: 2022-01-16
  • Updated: 2022-01-20
  • Resolved: 2022-01-20
Related Reports
Duplicate :  
JDK-8088897 - Menu.onAction may not be called when TextInputControl node is focused
Description
If a MenuBar set as systemMenuBar has a menuItem with an accelerator that uses as key combination Cmd+V, and the scene has a focused text input control, pressing Cmd+V pastes twice the content of the clipboard.

Originally posted at: https://github.com/javafxports/openjdk-jfx/issues/370, and added as a comment to JDK-8205915.

However, the current PR for JDK-8205915, https://github.com/openjdk/jfx/pull/715, doesn't fix it.

The issue has also been discussed in JDK-8242544. In fact, there was a closed PR https://github.com/openjdk/jfx/pull/704 that fixed it, by removing a duplicate call in performKeyEquivalent. However, the accepted fix https://git.openjdk.java.net/jfx/pull/714 does not fix it.

A proper fix should take into consideration that Cmd+V should be handled by the textField directly and the MenuItem should not fire at all.
Comments
Closing as a duplicate of JDK-8088897 per the above comment.
20-01-2022
This bug is a duplicate of https://bugs.openjdk.java.net/browse/JDK-8088897 and https://bugs.openjdk.java.net/browse/JDK-8087863 (which I really should update). The test case is a little confusing since the MenuItem accelerator and the textField binding do exactly the same thing (paste into the field). PR #704 was not a proper fix because the MenuItem fired and the textField did not handle the event. The cleanest solution to all of these bugs is to ensure that performKeyEquivalent returns YES if JavaFX consumes the event. This would allow the textField to handle the event first and keep the MenuItem from firing. Unfortunately there's currently no way for the glass code to determine that the event was consumed. The plumbing to do this was added to https://github.com/openjdk/jfx/pull/694 not because the issues are related but because both involve touching the same JNI calls and key event dispatch paths. So a fix is in progress.
18-01-2022
[~mfox] Any thoughts on this?
18-01-2022