JDK-7040632 : Plugin2 blocks FireFox when loading applet
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 6u24
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: linux
  • CPU: x86
  • Submitted: 2011-04-29
  • Updated: 2015-11-07
  • Resolved: 2011-12-19
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 7 JDK 8
7u4Fixed 8 b18Fixed
Related Reports
Relates :  
JDK-7148295 - REGRESSION: 7u4 Applets wont load with Chrome
Relates :  
JDK-7133019 - REGRESSION:7u4 b07 Applets wont load with Chrome
Relates :  
JDK-8133523 - _releaseObject called from wrong thread
Relates :  
JDK-8016849 - Applets don't get loaded and the Firefox crashes under Mac OS X
Description
FULL PRODUCT VERSION :
java version "1.6.0_25"
Java(TM) SE Runtime Environment (build 1.6.0_25-b06)
Java HotSpot(TM) Server VM (build 20.0-b11, mixed mode)


ADDITIONAL OS VERSION INFORMATION :
Fedora Linux 14

Linux localhost.localdomain 2.6.35.12-88.fc14.i686 #1 SMP Thu Mar 31 22:12:38 UTC 2011 i686 i686 i386 GNU/Linux

EXTRA RELEVANT SYSTEM CONFIGURATION :
FireFox 3.6 / 4.0

A DESCRIPTION OF THE PROBLEM :
When loading Applets, Plugin2 completly locks the browser on Linux (on Windows, the browser is still responsive while loading applets).

I've developed a huge Applet (all in all 15mb jar files), which takes minutes to load over slow connection the first time. During all this time FireFox is completly unresponsive and blocked (doesn't even repaint itself).
The slow loading isn't a huge problem, the few users using the Applet remotly are informed about this issue. However because the browser is blocked, often they kill the browser because they think its hung.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Load a huge Applet with FireFox+Linux

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
While the applet is loading, the browser should stay responsive.
The user should be able to user the browser for browsing during the Plugin is downloading the applet.
ACTUAL -
The browser is completly blocked.

REPRODUCIBILITY :
This bug can be reproduced always.
Comments
Verfied ok with jdk8 b112 on linux. The original link to verify the bug is gone but I used a couple of real world appelts with large size to test.
26-11-2013
SUGGESTED FIX The blocking factor on browser rendering, other than LiveConnect call, is mainly the initialization of server JVM, which in turn launch the client VM to run the applet. Client VM runs applet in a separate process, thus won't actually block browser. Although usually initialize a VM should not be a long process, but it can still happen depending on configuration. An extreme example, what if Java is on a remote shared folder? The proposed solution is to hand over the starting of an applet into a separate thread so that the browser can continue rendering the rest of content. The webrev can be found at http://sa.sfbay.sun.com/projects/deployment_data/8/7040632.4/ Risk: High, particular on browser interacting with applet later on. As the asynchonous start of applet, browser get back control earlier. LiveConnect call are synchronous and suppose to keep the browser blocked until applet is ready. Asynchonrous status callback is recommened to start liveconnect call to get best experience not blocking browser.
02-12-2011
EVALUATION Can we have a test case along with logs? I wonder the reporter is using IceTea or old plugin instead of plugin2. As plugin2 will launch a separate client VM to load the applet, the blocking factoring should limited to spawning process.
14-10-2011