This is a P3. It is now too late for 11 even if it was fine when the
thread began.
Fixes for 11 must be P2 or higher and you will need to personally
run all jtreg + JCK tests as a minimum level of testing.
And CPlatformWindow fixes have not been very successful lately !
So you probably need to wait until the current TCK issue there is
resolved before
you can begin.
I'm also curious if this even matters for 11 which has no applet support
- although
I do recognise EmbeddedFrame is used in other scenarios too.
But if this is just to enable a backport, then perhaps rushing it into
11 GA is not needed.
-phil.
On 8/4/18, 5:13 PM, Sergey Bylokhov 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.
