<AWT Dev> [8] Request for review: JDK-8016555: Regression: Focus issues with Oracle WebCenter Capture applet
Anton V. Tarasov
anton.tarasov at oracle.com
Fri Jun 14 05:41:09 PDT 2013
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.
>>>
>>
>
More information about the awt-dev
mailing list