<AWT Dev> [8] Review request for JDK-8020209: [macosx] Mac OS X key event confusion for "COMMAND PLUS" (plan B)

[Anthony Petrov]

Hi Leonid,

The problem with overriding NSApplication -sendEvent: is that you can't 
be sure AWT is running with the NSApplicationAWT instance. If using SWT, 
FX, or otherwise embedding AWT into another application, the NSApp will 
point to an instance of another application class, and your sendEvent: 
will never be called. I'd suggest to avoid using this method altogether 
if possible.

I see that webrev.01 also includes the changes in NSApplicationAWT.m. Is 
this really necessary for that version of the fix?

I recall in your original review request you stated that the code 
currently consists of multiple workarounds, and adding another one could 
just bring more regressions or unexpected behaviors. So I'd actually 
prefer the version .01.

Anyway, here's a couple of comments regarding the new fix:

src/macosx/native/sun/awt/AWTView.m
>  313     NSUInteger modFlags = [event modifierFlags] &
>  314         (NSCommandKeyMask | NSAlternateKeyMask | NSShiftKeyMask | NSControlKeyMask);
>  315     if (modFlags == NSCommandKeyMask) {

Do I understand correctly that OS X is fine with e.g. Shift+Cmd+'+', and 
only Cmd+'+' is causing a problem?

>  311     // Workaround for 8020209: special case for "Cmd =" and "Cmd ."
>  312     // because Cocoa calls performKeyEquivalent twice for these keystrokes

Interesting that you say that Cocoa sends multiple events and I'd guess 
one wants to filter some events out. However, at line 320 you call 
performKeyEquivalent yourself. Is this like the third call or something? 
Or the comment seems to be misleading otherwise.

--
best regards,
Anthony

On 10/16/2013 08:53 PM, Leonid Romanov wrote:
> Hello,
> This is plan B version of the fix for JDK-8020209: [macosx] Mac OS X key event confusion for "COMMAND PLUS". The previous, proper version of the fix has been reviewed here:
> http://mail.openjdk.java.net/pipermail/awt-dev/2013-September/005441.html
> Unfortunately, I can't proceed with that version because there are some difficulties with submitting private JDK 8 build to Apple for approval.  Since we are short on time and I want to fix this bug in JDK 8, I've had to use a workaround.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8020209
> webrev: http://cr.openjdk.java.net/~leonidr/8020209/webrev.02/
>
> Thanks,
> Leonid.
>
>
>