Hi Dmitry,
Looks fine to me too.
Regards,
Alexey
On 06/08/2018 15:43, Dmitry Markov wrote:
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.
