Thanks!
On 6/19/2013 16:17, Anthony Petrov wrote:
The fix looks fine to me, too.
--
best regards,
Anthony
On 06/14/2013 04:41 PM, Anton V. Tarasov wrote:
Thank you for the review.
On 14.06.2013 16:17, Leonid Romanov wrote:
Looks good then.
On 6/14/2013 16:10, Anton V. Tarasov wrote:
It's Ok because the check actually should be correct for any type of
toplevels.
Thanks,
Anton.
On 14.06.2013 10:54, Leonid Romanov wrote:
Hi,
The check you've added also affects lightweight frames (because of
line 382). Is it OK?
On 6/13/2013 6:52 PM, Anton V. Tarasov wrote:
Hello,
Please, review the fix.
jira: https://jbs.oracle.com/bugs/browse/JDK-8016555
webrev: http://cr.openjdk.java.net/~ant/JDK-8014821/webrev.0
It's reproducible in the applet mode only, on Windows. When an
applet is focused and then a new frame pops up, it doesn't get
focus.
The reason of the focus loss is the following. When a toplevel is
shown while another toplevel is focused, native focus messages
should be generated strictly in the following order:
WM_ACTIVATE(WA_INACTIVE), WM_ACTIVATE(WA_ACTIVE), appropriately.
The case with applet is special due to the EmbeddedFrame is not a
toplevel from native platform perspective, the toplevel is the
browser window. Moreover, the EmbeddedFrame window belongs to
another process, other than the browser's process. It doesn't
receive WM_ACTIVATE messages, these messages are generated
(synthesized) for it when it should be activated/deactivated as an
AWT toplevel. When EmbeddedFrame loses focus it receives
WM_KILLFOCUS (which is triggered by the plugin). However, in case
when a new frame pops up, the EmbeddedFrame receives WM_KILLFOCUS
after the frame receives WM_ACTIVATE(WA_ACTIVE). So the order is
not correct. The reason is the specific of IPC: browser -> plugin
-> applet (another process).
When EmbeddedFrame receives WM_KILLFOCUS it synthesizes
WM_ACTIVATE(WA_INACTIVE) for itself. On processing of this message,
AwtComponent::SetFocusedWindow() static method is called which
resets the native pointer to the focused window. The point is that
as the message is received after WM_ACTIVATE(WA_ACTIVE) (which is
sent to the new frame), the new focused window is set to NULL.
Later, when focus is requested to the frame's default component, it
gets rejected because of the null native focused window value.
Before the regression, there was a check for opposite toplevel
being set focused in processing of WM_KILLFOCUS for EmbeddedFrame.
In case the opposite toplevel is already set focused (which means
it already received WM_ACTIVATE(WA_ACTIVE)), no
WM_ACTIVATE(WA_INACTIVE) message was synthesized. DKFM in that case
created a peer WINDOW_LOST_FOCUS event on java level for the
toplevel losing focus (EmbeddedFrame in our case). This code was
lost in the process of refactoring and I'm simply bring it back.
I've tested it manually with the applet provided in the bugreport
(with IE and FF).
As the fix simply makes the code spot look like it was before the
regression, I consider it low risk.
Thanks,
Anton.
P.S.
I'm going to push it to 7u40 as well.
