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

[Leonid Romanov]

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.
>>
>