<AWT Dev> [8] Request for review: JDK-8016555: Regression: Focus issues with Oracle WebCenter Capture applet

[Anton V. Tarasov]

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.