On Fri, 14 Jan 2022 00:55:00 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. > > 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. I just started to look at this and noticed that this PR is based off of the current `master`, and has commits not in `jfx18`. You will need to rebase to `jfx18` and force-push to your branch. ------------- PR: https://git.openjdk.java.net/jfx/pull/715
