JDK-6228734 : filechoser dialogue can not be controled by mouse in 1.4.2_07
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 1.4.2_07
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2005-02-14
  • Updated: 2010-08-03
  • 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-6239224 - IE hangs when a modal dialog is active and the mouse is clicked on the browser
Description
A customer reported that they can not control a dialogue.

REPRODUCE:
 
 (1) Place the attached f3hkafja.jar and fc_applet.html under the same dir.
 (2) Invoke the html file in Internet Explorer.
     An IE window with "save" and "read" buttons will show up.
 (3) Click the "read" button. Then small confirmation dialogue shows up
     and click "ok".
     (Please see the attached clicking-read.jpg)
 (4) FileChoser dialogue shows up.
     (Please see the attached clicking-ok-in-dialog.jpg)
     However,
       - can not enter any characters in file name field in the dialoge.
       - can not click "cancel" button

  NOTE TO REPRODUCE
    - Don't click or operate other windows and dialogues.
      If you do that, you can control the dialogue normally.

CONFIGURATION :
  JRE : 1.4.2_07
  OS  : WindowsXP (SP1, japanese)
  Browser : IE6.0(SP1)

###@###.### 2005-2-14 07:28:26 GMT
Comments
EVALUATION I am able to reproduce the bug on 1.4.2_07 and is a regression on this release. The bug occurs only in the browser(IE). - The bug occurs only when you bringup the filedialog by invoking it through javascript from a html button. - It doesn't occur when you invoke it through the action listener of a button (say AWT Button) within the applet. More investigation being done. ###@###.### 2005-2-26 00:06:34 GMT After further investigation, it's figured out that the bug is a regression introduced from the plugin fix for bugs(5077565,5079850). The main thread (Javascript thread) doesn't receive any windows messages and hence hangs(or sometimes looks hung). ###@###.### 2005-03-02 02:44:04 GMT Some more analysis done: - The bug also exists on 1.5.0, 1.5.0_xx. - The bug is masked in 1.5.0 because the filechooser dialog lost its modality for whatever reasons and hence appeared to work well - In 1.5.0_u3, the dialog is modal and so the bug is visible again. There is also a nasty bug that I believe has existed all along (including tiger and 1.5 update releases). Haven't tested with mustang yet. When the modal dialog is active, click anywhere on the browser (other than the applet region), the browser hangs. The bug is there even in 1.4.2_06 and before. ###@###.### 2005-03-10 02:15:48 GMT
14-02-2005
SUGGESTED FIX I've the following suggested fix and I discussed it with Calvin Cheung. A lot of testing needs to be done to test the suggested fix to make sure it doesn't break anything else. JavaAdapter.cpp DWORD CJavaAdapter::WaitForJS(void *ptr, HANDLE hEvent, DWORD time) I would need to add code to split the behaviour between modal and non-modal dialogs. This is my proposal. - Determine if the active window is modal - If yes, pump windows messages (WM_PAINT ...) to the parent window. It's basically incorporating the code in WaitForJS that existed before fixing 5077565,5079850 - If no, pump the user messages to the parent window (i.e. fallback to the existing code) ###@###.### 2005-03-10 02:15:49 GMT
14-02-2005