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.
