JDK-6239224 : IE hangs when a modal dialog is active and the mouse is clicked on the browser
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 6
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows
  • CPU: generic
  • Submitted: 2005-03-11
  • Updated: 2010-12-07
  • Resolved: 2005-04-25
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 JDK 6
1.4.2_09 b01Fixed 6Fixed
Related Reports
Relates :  
JDK-6247308 - REGRESSION: Particular Applets won't work in IE anymore when using the latest Java plugin
Relates :  
JDK-6228734 - filechoser dialogue can not be controled by mouse in 1.4.2_07
Description
The bug occurs right from 1.4.2_07, to 1.5 update release and all the way to mustang current build (b26 at this point).
The bug occurs when a modal dialog is popped up through an applet through a Javascript.

STEPS TO REPRODUCE:
- Compile Test.java and launch the attached applet (Test.html)
- Click on the html (not applet) "Read" button
- A filedialog pops up. Click anywhere on the browser (except the applet region). The browser hangs.

###@###.### 2005-03-11 01:57:20 GMT
Comments
EVALUATION Problem: When an AWT modal dialog is popped up through Javascript(only) the browser window doesn't receive any windows messsages and hence hangs most of the times. In this bug, the modal dialog popped up is a FileDialog and doesn't receive any key/mouse events. This regression is a side effect of fix for 5077565,5079850. The previous fix removed code for pumping messages to the browser window while a modal dialog is active and only user messages are dispatched. Fix: The fix proposed here is to have different codepaths (one when a modal dialog is active and the other when it is not). The fix checks for the existence of the modal dialog in the do-while loop of JavaAdapter::WaitForJS(...) method. This has to be done because WaitForJS gets called before the modal dialog comes up and so GetActiveWindow will never point to the dialog unless put into the loop. In summary, When modal dialog is active -> pump windows messages to the browser window When modal dialog is not present -> pump user messages (code that currently exists after fix for 5077565,5079850) ###@###.### 2005-03-23 19:40:07 GMT
11-03-2005