On Thu, 13 Jan 2022 19:18:33 GMT, Martin Fox <d...@openjdk.java.net> wrote:
> When a window is closed while handling performKeyEquivalent the same NSEvent > might be passed to the new key window causing it to being processed twice. > Long ago a fix was put in for this case; when the GlassWindow was closed a > flag was set to ensure that we would return YES from performKeyEquivalent. To > fix RT-39813 the closing of the window was deferred causing the flag to be > set too late. This PR simply sets that flag when we schedule the close event > instead of when the OS actually closes the window. > > This is a spot-fix for a larger problem, namely that we have no way of > knowing whether a performKeyEquivalent event was consumed or not. The changes > for fixing that are in PR #694. The changes got bundled into that PR only > because there's a lot of files involved and the exact same code paths are > touched. > > System test is included (I'm surprised, it really is possible to generate > Cmd+Enter using a Robot). This is new territory for me so I have a manual > test I can submit as a backup. This pull request has now been integrated. Changeset: 217e086b Author: Martin Fox <belden...@users.noreply.github.com> Committer: Kevin Rushforth <k...@openjdk.org> URL: https://git.openjdk.java.net/jfx/commit/217e086b3493dfc7d419d8fa632a9d3091e7f823 Stats: 170 lines in 2 files changed: 170 ins; 0 del; 0 mod 8205915: [macOS] Accelerator assigned to button in dialog fires menuItem in owning stage Reviewed-by: jpereda, kcr ------------- PR: https://git.openjdk.java.net/jfx/pull/715
