<AWT Dev> [11] RFR 8130655: OS X: keyboard input in textfield is not possible if the window contained textfield is owned by EmbeddedFrame

Dmitry Markov dmitry.markov at oracle.com
Mon Aug 6 12:43:01 UTC 2018

Thank you, Sergey!

Looking for the second +1 from someone else.


> On 5 Aug 2018, at 01:13, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
> Looks fine.
> On 30/06/2018 08:12, Dmitry Markov wrote:
>> Hi Sergey,
>>> On 27 Jun 2018, at 01:15, Sergey Bylokhov <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>>> Hi, Dmitry.
>>> Can you please provide some more details why this bug is reproducible only on mac and not on the other platforms(I meant the bug related to the popup menu not SHOULD_BECOME_KEY and SHOULD_BECOME_MAIN bits)
>> The implementation of EmbeddedFrame on Mac OSX is lightweight and it is heavyweight on Window/Linux. In other words on Windows/Linux an embedded frame is able to receive events from the platform by itself and transfer them to its child windows if any. However it does not work for Mac OSX: CEmbeddedFrame receives events only from the embedder, (e.g. browser) which is not aware of any windows owned by the embedded frame. So on Mac OSX if the embedded frame owns a simple window (which is unfocusable by default) there is no way to provide the simple window with keyboard input. At the same time on other platforms the simple window receives key events in the same scenario.
>> The test applet attached to the bug demonstrates the problem, (i.e. simple window owned by embedded frame is unable to receive keyboard input) on Mac and its absence on other platform. Currently I have only this test which works on all platforms without any modifications.
>>> I have checked our current behavior on win/lin/mac in all cases the simple "Window" cannot get a focus, without any difference which parent is used(null/frame/window).
>>> So for example if the window1 is owned by another window2, then both of them are "unfocusable", but after the current fix, both will be "focusable" if the window2 will be owned by the embedded frame.
>> I agree it was not good idea to make simple window focusable even if it was owned by embedded frame. I think it will be better to allow simple window receive keyboard input if it is owned by embedded frame. In other words simple window will stay unfocusable, (i.e. SHOUL_BECOME_MAIN and SHOULD_BECOME_KEY bits are unset) but it will be able to receive key events when necessary. Please find the implementation of this approach here: http://cr.openjdk.java.net/~dmarkov/8130655/webrev.01/ <http://cr.openjdk.java.net/%7Edmarkov/8130655/webrev.01/>
>> Changes:
>>  - Added methods CPlatformWindow and AWTWindow to check whether the window is simple and owned by embedded frame
>>  - Modified canBecomeKeyWindow() in AWTWindow to take into account window type and owner
>> Could you review the new version, please?
>> Thanks,
>> Dmitry
>>> On 25/06/2018 03:35, Dmitry Markov wrote:
>>>> Hello,
>>>> Could you review a fix for jdk11, please?
>>>>  bug: https://bugs.openjdk.java.net/browse/JDK-8130655
>>>>  webrev: http://cr.openjdk.java.net/~dmarkov/8130655/webrev.00/ <http://cr.openjdk.java.net/%7Edmarkov/8130655/webrev.00/>
>>>> Problem description:
>>>> On OS X platform a window does not receive keyboard input if it is owned by embedded frame. According to the current implementation “simple window” (not frame or dialog) is NOT natively focusable, (i.e. SHOULD_BECOME_KEY and SHOULD_BECOME_MAIN bits are not set for its native peer); embedded frame receives events from the embedder, (e.g. browser, etc.) but does not translate them to the its own child windows. So if “simple window” is owned by embedded frame it is impossible for the window to receive any key events.
>>>> Fix:
>>>> Set SHOULD_BECOME_KEY and SHOULD_BECOME_MAIN bits for simple window which is owned by embedded frame.
>>>> Thanks,
>>>> Dmitry
>>> -- 
>>> Best regards, Sergey.
> -- 
> Best regards, Sergey.

More information about the awt-dev mailing list