|
Evaluation
|
The root cause of the problem is very subtle, relating to the threading model of the web browser and how the Java Plug-In schedules work to be done on the browser's main thread, but the fix is extremely simple: do not detach the browser's main thread from the JVM upon Java Plug-In shutdown. The detaching and reattaching causes the identity of the java.lang.Thread corresponding to the browser's main thread to change over time, breaking Java-level logic in the new Java Plug-In.
Posted Date : 2008-10-17 20:58:22.0
While running the LiveConnect conformance tests on Firefox 3 on Unix
platforms, it was discovered that reloading the page would hang the
browser.
The root cause of the hang is related to how asynchronous events are
processed on the browser's main thread, and the definition of the
browser main thread itself. Essentially, the Java Plug-In assumes that
the java.lang.Thread associated with the browser's main thread is
stable. Early in the 6u10 release a Yokogawa resource leak was fixed
(6630062) and during that fix it was discovered that detaching the
browser's main thread introduced then-unknown resource leaks on
Windows. Now it is understood that in the Firefox plug-in, the
resource leak was a Java-level one, caused by the java.lang.Thread
associated with the browser's main thread changing at unexpected
times.
The correct fix under the circumstances is to not detach the browser's
main thread from the JVM upon destruction of the Java Plug-In
instance. This has the potential of introducing resource leaks in
NPAPI browsers that have a main thread per browser window; it is not
known whether any exist at the present time, but Firefox definitely
only has one main thread for all of its windows. Comments have been
added to the code describing this potential situation.
Posted Date : 2008-10-18 05:27:50.0
|
