United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: 6228734 filechoser dialogue can not be controled by mouse in 1.4.2_07
6228734 : filechoser dialogue can not be controled by mouse in 1.4.2_07

Details
Type:
Bug
Submit Date:
2005-02-14
Status:
Resolved
Updated Date:
2010-08-03
Project Name:
JDK
Resolved Date:
2005-04-25
Component:
deploy
OS:
windows_xp
Sub-Component:
plugin
CPU:
x86
Priority:
P3
Resolution:
Fixed
Affected Versions:
1.4.2_07
Fixed Versions:
1.4.2_09

Related Reports
Backport:
JDK-2124459 - filechoser dialogue can not be controled by mouse in 1.4.2_07
Backport:
JDK-2124525 - filechoser dialogue can not be controled by mouse in 1.4.2_07
Relates:
JDK-6239224 - IE hangs when a modal dialog is active and the mouse is clicked on the browser
Relates:
JDK-6247308 - REGRESSION: Particular Applets won't work in IE anymore when using the latest Java plugin

Sub Tasks

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
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
2005-02-14 
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
2005-02-14


Hardware and Software, Engineered to Work Together