> 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.
Martin Fox has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/715/files - new: https://git.openjdk.java.net/jfx/pull/715/files/fc24f9c7..fc24f9c7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=715&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=715&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/715.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/715/head:pull/715 PR: https://git.openjdk.java.net/jfx/pull/715
