> 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 incrementally with one additional commit since the last revision: Renamed test to match existing conventions along with minor cleanup. ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/715/files - new: https://git.openjdk.java.net/jfx/pull/715/files/edebba96..4962a1fb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=715&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=715&range=02-03 Stats: 10 lines in 1 file changed: 0 ins; 5 del; 5 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
