United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6938377 Successive JavaScript dialog via LiveConnect lose focus, cannot operate by keyboard
JDK-6938377 : Successive JavaScript dialog via LiveConnect lose focus, cannot operate by keyboard

Details
Type:
Bug
Submit Date:
2010-03-26
Status:
Closed
Updated Date:
2011-03-02
Project Name:
JDK
Resolved Date:
2010-11-25
Component:
client-libs
OS:
windows_vista
Sub-Component:
java.awt
CPU:
x86
Priority:
P2
Resolution:
Fixed
Affected Versions:
5.0u17
Fixed Versions:
5.0u17-crev (b04)

Related Reports
Backport:
Relates:
Relates:

Sub Tasks

Description
Vista, IE7 + 1.5.0_17 - 1.5.0_22

When an applet shows several JavaScript dialog via LiveConnect, second and
later dialog does not have focus, thus user cannot operate it by keyboard.

I don't see this symptom on XP/IE6.

                                    

Comments
EVALUATION

I have verified that the following sequence of actions happens in
the test case when "Test 1" button is pressed.

1. The focus is transferred from "IExplorerEmbeddedFrame" window to
   "SunAwtCanvas" window (WM_KILLFOCUS/WM_SETFOCUS).
2. "confirm dialog: 0" dialog is open.
3. The focus is transferred from "SunAwtCanvas" window to
   "OK" button of "confirm dialog: 0" dialog (WM_KILLFOCUS).
   AwtComponent::WmKillFocus() synthesizes WM_ACTIVATE message
   for deactivation of "IExplorerEmbeddedFrame" window.
   AwtFrame::WmActivate() processes this message.
4. Java Plug-in processes a callback from IE -
   CAxControl::OnFrameWindowActivate() (for deactivation) -
   and calls CJavaFrame::deactivate().
   This method synthesizes another WM_ACTIVATE message
   for deactivation of "IExplorerEmbeddedFrame" window.
   AwtFrame::WmActivate() processes this message.

When "OK" button of "confirm dialog: 0" dialog is pressed:

5. "SunAwtCanvas" window receives WM_SETFOCUS message.
   AwtComponent::WmSetFocus() synthesizes WM_ACTIVATE message
   for activation of "IExplorerEmbeddedFrame" window.
   AwtFrame::WmActivate() processes this message and calls
   ::SetFocus(NULL).
   "SunAwtCanvas" window receives and processes the corresponding
   WM_KILLFOCUS message.
6a. "confirm dialog: 0" dialog is closed, and just after that
    "confirm dialog: 1" dialog is open.
6b. Java Plug-in processes a callback from IE -
    CAxControl::OnFrameWindowActivate() (for activation) -
    and calls CJavaFrame::activate().
    This method synthesizes WM_ACTIVATE message
    for activation of "IExplorerEmbeddedFrame" window.
    AwtFrame::WmActivate() processes this message.
    * I have verified that at this point the native focus
      belongs to "OK" button of "confirm dialog: 1" dialog.
    AwtFrame::WmActivate() issues ::SetFocus(NULL). This call
    removes the focus from "OK" button of the dialog and
    causes the issue.
7. Java Plug-in processes a callback from IE -
   CAxControl::OnFrameWindowActivate() (for deactivation) -
   and calls CJavaFrame::deactivate().
   This method synthesizes WM_ACTIVATE message
   for deactivation of "IExplorerEmbeddedFrame" window.
   AwtFrame::WmActivate() processes this message.

For every next dialog steps 6a, 6b, and 7 are repeated.
                                     
2010-10-15
SUGGESTED FIX

The code review request:
http://jpsesvr.sfbay.sun.com:8080/ctetools/html/ViewDetail.jsp?index=3822
                                     
2010-11-09
EVALUATION

This issue was fixed together with CR 6928397 and CR 6978742.

All three issues are linked to ::SetFocus(NULL) call in awt_Frame.cpp.
The previous fix for CR 6928397 removed that call but it caused a regression
CR 6978742. To fix both these issues, ::SetFocus(NULL) call was restored, and
another fix was introduced in awt_Component.cpp. But, in turn, it caused
the symptomes of CR 6938377. This problem was fixed by introducing a new
condition around ::SetFocus(NULL) call which excluded a set of situations
when the call is not desired.
                                     
2010-11-09



Hardware and Software, Engineered to Work Together