United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6523707 IE browser thread dead after modal dialog created from liveconnect in another window
JDK-6523707 : IE browser thread dead after modal dialog created from liveconnect in another window

Details
Type:
Bug
Submit Date:
2007-02-10
Status:
Resolved
Updated Date:
2011-03-26
Project Name:
JDK
Resolved Date:
2007-04-11
Component:
deploy
OS:
solaris,windows_xp,windows
Sub-Component:
plugin
CPU:
x86,sparc
Priority:
P3
Resolution:
Fixed
Affected Versions:
6.2p9,5.0u6,5.0u10
Fixed Versions:
5.0u12 (b03)

Related Reports
Backport:
Backport:
Backport:
Backport:
Relates:
Relates:
Relates:

Sub Tasks

Description
The system consists of an applet embedded in in an IEExplorerEmbeddedFrame.  It provides computational services through Live Connect.  The only UI that it uses are dialogs.  When the applet is called from Javascript that is from a different window than the window where the applet is embedded, it will cause the browser thread to die after a modal dialog is put up.  Java script on the browser is still functional as well as the applet as it can still be called through live connect.  HTTP is dead in the main window.  Window widgets in IE still work.

                                    

Comments
SUGGESTED FIX

To workaround the hang issue, please refer to the "new_TestApplet.java" in the attachement.

To workaround the requestFocus issue, plase refer to the "new_testcbild.html" in the attachment.
                                     
2007-03-05
EVALUATION

The are at least 2 problems associated with this bug.
1) browser hangs when action3() of the testcase is performed. It is strictly not a defect in the jdk because the GUI operation isn't being performed in the event dispatch thread. Wrapping the action3() with SwingUtilities.invokeLater fixes the problem.

2) calling requestFocus from javascript doesn't bring the IE browser window into focus.
There's a workaournd to this by using the opener.focus() from javascript.

Since the submitter indicated that this is different from a deadlock issue the customer is reporting and there's a workaround, I'm lowering the priority of this bug to P3.
                                     
2007-03-05
SUGGESTED FIX

In WaitForJS function call in JavaAdapter.cpp, the section for code for modal dialog, the mask we use in the MsgWaitForMultipleObjects, is QS_ALLINPUT . This value is a combination of QS_INPUT, QS_POSTMESSAGE, QS_TIMER, QS_PAINT, and QS_HOTKEY. We were processing PAINT and TIMER message, the rest were just getting removed from the queue without processing, hence the issue.

I've modified code to process all messages received with this mask.
                                     
2007-04-06



Hardware and Software, Engineered to Work Together