JDK-6523707 : IE browser thread dead after modal dialog created from liveconnect in another window
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 6.2p9,5.0u10,5.0u6
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris,windows,windows_xp
  • CPU: x86,sparc
  • Submitted: 2007-02-10
  • Updated: 2011-03-26
  • Resolved: 2007-04-11
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other Other JDK 6 JDK 7
1.4.2_17-revFixed 1.4.2_18Fixed 6u4Fixed 7Fixed
Related Reports
Relates :  
JDK-6395737 - IE hangs when a modal dialog is active with concurrent window re-focus activities
Relates :  
JDK-6572970 - dialogue request window pops under the current focus window
Relates :  
JDK-6538154 - requesting focus on applet doesn't bring the browser to front
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 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.
06-04-2007
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.
05-03-2007
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.
05-03-2007