JDK-6675834 : (Nightly) : Some of the Liveconnect scenarios are making browser to hang when run with new Plug-in
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 6u10
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: windows
  • CPU: generic
  • Submitted: 2008-03-15
  • Updated: 2010-09-08
  • Resolved: 2008-05-15
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.
JDK 6
6u10 b21Fixed
Related Reports
Relates :  
JDK-6669444 - Firefox crashes when doing a typeof=="object" check on an object
Relates :  
JDK-6683082 - Firefox 3 crashes while running a Liveconnect test case with the new Plug-in
Relates :  
JDK-6668037 - Slow client JVM initialization at applet launch time
Relates :  
JDK-6742814 - In Java to JavaScript communication, JSObject.getWindow().call() locks up IE
Description
Build Tested : Nightly build dated March 13th

Some of the applets testing scenarios related to liveconnect are making browser to hang when run with new PLug-in. Hang is not reporducible with the old Plug-in.
Hang can be seen across all the new Plug-in supported browsers i.e. IE6,IE7 and FF3

Steps to reproduce:
-------------------
1) Install the nightly bundle dated March-13
2) Try loading the following applet inside the browser
http://sqeweb.sfbay.sun.com/deployment2/jitu/plug-bug/ojiliveconnect/src/HashTableTest.html

If the browser hangs then bug is reproduced
Comments
SUGGESTED FIX testcase: http://j2se.east.sun.com/deployment/www/tests/1.6.0_10/6675834/ testcase: http://sqeweb.sfbay.sun.com/deployment2/jitu/plug-bug/ojiliveconnect/src/HashTableTest.html webrev: http://sa.sfbay.sun.com/projects/deployment_data/6u10/6675834.5 workspace: deploy engineer: sven.gothel
16-03-2008
SUGGESTED FIX 6675834 : Some of the Liveconnect scenarios are making browser to hang when run with new Plug-in [Kenneth Russell] Also Fixes: 6668037 : Slow client JVM initialization at applet launch time Misc Fixes: - Proper DeployPerfUtil initilization and generic PerfHelper for Unix With the latest patch CR 6673085 (AddingRobustnessToLiveConnectsResultHandler), we wait until 'appletReady' which is _after_ the user init() call, until the server actually sends all AppletMessages queued so far. This point in time 'appletReady' is too late and different than the implementation before. The pre CR 6673085 code just waited until the applet reference became != null, i.e. the applet was successfully loaded. Now, we added the state transition of 'appletLoaded' in the Applet2Listener, so the server can use this point in time (StartAppletResultMessage.APPLET_LOADED), to drain the AppletMessage queue. This approach is more correct and equal to the original implementation. This fix also allowed us to remove the client side locking and tracking of the applet status, i.e. remove the 'Underway' status and the Applet2Listener in client LiveConnectSupport. Locking for LiveConnect operations before applet's init() method has been called, is done in Plugin2Manager, and it's 'waitUntilAppletInitDone()' method. +++
16-03-2008
SUGGESTED FIX This fix also allowed us to remove the client side locking and tracking of the applet status, i.e. remove the 'Underway' status and the Applet2Listener in client LiveConnectSupport.
15-03-2008
SUGGESTED FIX With the latest patch CR 6673085 (AddingRobustnessToLiveConnectsResultHandler), we wait until 'appletReady' which is _after_ the user init() call, until the server actually sends all AppletMessages queued so far. This point in time 'appletReady' is too late and different than the implementation before. The pre CR 6673085 code just waited until the applet reference became != null, i.e. the applet was successfully loaded. Now, we added the state transition of 'appletLoaded' in the Applet2Listener, so the server can use this point in time (StartAppletResultMessage.APPLET_LOADED), to drain the AppletMessage queue. This approach is more correct and equal to the original implementation.
15-03-2008
EVALUATION Reproduces on GNU/Linux FF3. A 'GetAppletMessage' is spooled and not drained, which causes the browser to freeeze.
15-03-2008
EVALUATION Reproducible with the latest plugin code. Must be a recent regression because this test case used to work.
15-03-2008