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

[Sergey Bylokhov]

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.