Thank you, Sergey! Looking for the second +1 from someone else.
Thanks, Dmitry > On 5 Aug 2018, at 01:13, Sergey Bylokhov <[email protected]> wrote: > > Looks fine. > > On 30/06/2018 08:12, Dmitry Markov wrote: >> Hi Sergey, >>> On 27 Jun 2018, at 01:15, Sergey Bylokhov <[email protected] >>> <mailto:[email protected]>> 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.
