JDK-6247308 : REGRESSION: Particular Applets won't work in IE anymore when using the latest Java plugin
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 1.4.2_07
  • Priority: P2
  • Status: Closed
  • Resolution: Won't Fix
  • OS: windows_2000
  • CPU: x86
  • Submitted: 2005-03-29
  • Updated: 2011-02-16
  • Resolved: 2008-12-19
Related Reports
Relates :  
JDK-6395737 - IE hangs when a modal dialog is active with concurrent window re-focus activities
Relates :  
JDK-6239224 - IE hangs when a modal dialog is active and the mouse is clicked on the browser
Relates :  
JDK-6228734 - filechoser dialogue can not be controled by mouse in 1.4.2_07
Relates :  
JDK-5077565 - Java Script event handlers issue.
Description
It's about a regression problem, observed when running particular Applets in IE and using latest Java plugins like 1.4.2_07 or 1.5.0_02.

A testcase including sources has been added to this change request.

How to reproduce the problem:
- unzip the TestCase.zip
- install a particular JRE (see prolem matrix)
- load test.html in your browser (see problem matrix)
- There are three clickable objects on the test page
- Click on the link called "Collect Input"
  Moving your mouse pointer about the applet panel displayed
  should result in the progress bar updating from 0 to 100% before the
  panel disappears. The 1st link always works.
- Click on the 2nd or 3rd button
  The window pops up, but nothing else happens anymore if you use IE
  and any newer JRE (see problem matrix)
  
It is a regression bug, introduced in 1.4.2_07 and 1.5.0_01, because the problem only appears when using Internet Explorer and latest JREs. The problem can't be detected with Mozilla-based browsers, like Firefox OR when using older JREs and IE. See the problem matrix for more information.

Problem matrix, tests have been made on Windows 2000 SP4:
JRE         IE 6.0.2800.1106     Firefox 1.0
--------------------------------------------
1.4.2_06    ok                   ok
1.4.2_07    problem              ok
1.4.2_09*   problem              ok

1.5.0       ok                   ok
1.5.0_01    problem              ok
1.5.0_02    problem              ok 

*java full version "1.4.2_09-nb-20050323"

###@###.### 2005-03-29 13:06:49 GMT
Comments
SUGGESTED FIX ------- JavaAdapter.cpp ------- *** //C/tmp/sccs.001000 Fri Oct 27 16:51:31 2006 --- JavaAdapter.cpp Fri Oct 27 16:08:53 2006 *************** *** 1,5 **** /* ! * %W% %E% * * Copyright 2005 Sun Microsystems, Inc. All rights reserved. * SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. --- 1,5 ---- /* ! * @(#)JavaAdapter.cpp 1.17 06/07/30 * * Copyright 2005 Sun Microsystems, Inc. All rights reserved. * SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. *************** *************** *** 456,470 **** dwRet = MsgWaitForMultipleObjects(1, &hEvent, FALSE, time, QS_ POSTMESSAGE|QS_SENDMESSAGE); // If there is a message in the queue if (dwRet == WAIT_OBJECT_0 + 1 ) { ! MSG msg; while( PeekMessage(&msg, NULL, WM_JPI_MIN, WM_JPI_MAX, PM_ REMOVE)) { ! TranslateMessage(&msg); ! DispatchMessage(&msg); ! // Check if the JS-Java method is done(i.e event is si gnalled) ! if(WaitForSingleObject(hEvent, 0) == WAIT_OBJECT_0) { ! dwRet = WAIT_OBJECT_0; ! break; ! } } } }while(dwRet == WAIT_OBJECT_0+1); --- 459,483 ---- dwRet = MsgWaitForMultipleObjects(1, &hEvent, FALSE, time, QS_ POSTMESSAGE|QS_SENDMESSAGE); // If there is a message in the queue if (dwRet == WAIT_OBJECT_0 + 1 ) { ! MSG msg; ! PeekMessage(&msg, NULL, 0, 0, PM_NOREMOVE); ! if ((msg.message < WM_JPI_MIN) || (msg.message > WM_JPI_MA X)) { ! if (msg.message == 0x8002) { ! PeekMessage(&msg, msg.hwnd, msg.message, msg.messa ge, PM_REMOVE); ! TranslateMessage(&msg); ! DispatchMessage(&msg); ! } ! } while( PeekMessage(&msg, NULL, WM_JPI_MIN, WM_JPI_MAX, PM_ REMOVE)) { ! TranslateMessage(&msg); ! DispatchMessage(&msg); ! // Check if the JS-Java method is done(i.e event is signalled) ! if(WaitForSingleObject(hEvent, 0) == WAIT_OBJECT_0) { ! dwRet = WAIT_OBJECT_0; ! break; ! } } } }while(dwRet == WAIT_OBJECT_0+1);
27-10-2006
EVALUATION There's a message pump in the jpicom32.dll module in the CJavaAdapter::WaitForJS function. For the 2nd and the 3rd buttons of this test case, windows sends a user message 0x8002 to the dialog. And the mentioned message pump didn't dispatch that message and resulting in a hang. A fix is to dispatch the 0x8002 user message. See suggested fix for details. At this point, it's unclear how the user message is being triggered.
27-10-2006
EVALUATION The associated escalation has been resolved with the workaround provided to them The bug is still there. I am defering it for now.
07-07-2006
EVALUATION This is likely the same problem as: 6228734 : filechoser dialogue can not be controled by mouse in 1.4.2_07 6239224 : IE hangs when a modal dialog is active and the mouse is clicked on the browser Fix for the above will be available in the following J2SE releases: 1.4.2_09, 5.0u4, 6.0. For now, please test with internal promoted build and see whether the above evaluation is correct. ###@###.### 2005-04-12 16:43:24 GMT I did some investigation and I figured out that it may not be a plugin bug. I could reproduce the bug in a similar manner with a standalone. Please note that the bug is reproduceable with the "Collect Input" href link in the attached html as well. When the progress bar frame is active, click anywhere on the browser or do a ALT-TAB. The browser hangs! Attached Test.java to reproduce the bug as a standalone. - Compile and run Test.java - Click on the button. It brings up the progress bar frame. - The testcase looks hung. You cannot update the progress bar. You cannot click on the button in the first frame. The app cannot be closed. Looks to me as a testcase bug since the CollectInput() method of Test class blocks the event dispatch thread (EDT). Any time consuming process or a code of this kind should go into a non EDT thread (say by using the SwingWorkerThread) Try this out: Put the while loop in a separate thread (uncomment the threading code in Test.java) - Run the testcase and it works fine. Follow the same procedure as mentioned in the workaround and run the applet in IE browser. It works fine. At this point, I haven't figured out how the applet was working in some releases as mentioned by the submitter. ###@###.### 2005-04-12 23:39:09 GMT The Applet has only problems in IE and has worked in the past, therefore I still think that it's a regression bug, rather than a coding error. I have tested the original testcase with nightly build 1.4.2_09-nb-20050412, but the problem is still there. ###@###.### 2005-04-14 14:08:31 GMT - The problem here is with the modality behaviour of the dialog through plugin. This applet is a special case where a non modal frame is invoked but one of its method Applettester.CollectInput simulates a modality behaviour by entering into a while loop. This has worked on some of the earlier 1.4.2 update releases but they have had side effects. - As a workaround, replacing the Frame with a Dialog and setting it to Modal preserves the exact behaviour of the testcase. ###@###.### 2005-06-17 19:22:44 GMT
29-03-2005
WORK AROUND 1. Use a Mozilla based browser like Firefox rather than IE. ###@###.### 2005-03-29 13:06:50 GMT 2. Downgrade the Java plugin version Note: workarounds 1) and 2) don't help customer in esc# 1-7876418, because customer clearly can't control what browsers clients of his application are going to be using on their desktops (see also Justification section). 3. Provide a text based link rather than a button based link. Note: that workaround also doesn't help customer in esc# 1-7876418, they are completely against this, apparently it's not a simple re-write of one button, but would involve re-writing their entire UI (see also Justification section). ###@###.### 2005-04-04 08:59:26 GMT Workaround: Put the while loop in CollectInput() method inside a thread. Thread t = new Thread( new Runnable() { public void run() { while(fred.getProgress() < 100){ try { Thread.currentThread().sleep(200); } catch (InterruptedException ex) { } } fred.dispose(); } }); t.start(); ###@###.### 2005-04-12 23:39:10 GMT Use Dialog instead of Frame and make it modal. Please see the (modified) attached file CollectInput.java with the lines containing comments //workaround ###@###.### 2005-06-17 19:22:45 GMT
29-03-2005