Closed Bug 501173 Opened 15 years ago Closed 7 years ago

Java applet using LiveConnect hangs with Adblock Plus 1.0.2


(Core Graveyard :: Plug-ins, defect)

1.9.0 Branch
Not set


(Not tracked)



(Reporter: jwkbugzilla, Unassigned)



(Keywords: hang)


(3 files)

Forwarding a bug report from an Adblock Plus user, sounds very similar to bug 498399 and probably caused by the same issue but will supposedly only happen with newer Java versions. I couldn't reproduce on Windows, must be Linux-only again (will try to reproduce there later).

> After updating my Sun JRE from 1.6u7 to 1.6u10+ I noticed that Firefox (3.0.x)
> freezes and holds the CPU 100% busy when a Java applet calls getWindow() from
> the LiveConnect API. This goes away when disabling the Adblock Plus extension
> (1.0.2). In some very rare cases it works so I guess it is a race condition.
> With JRE 1.6u10 Sun implements the "New Java™ Plug-In Technology" (see
> which probably requires some
> changes.
> To reproduce try the following:
> (1) Compile the following Java applet:
>         import java.applet.Applet;
>         import netscape.javascript.JSObject;
>         import netscape.javascript.JSException;
>         public class LStest extends Applet {
>             JSObject win;
>             public void init() {
>                 System.out.println("init");
>                 win = JSObject.getWindow(this);
>                 System.out.println("init done");
>             }
>         }
>     E.g.: /opt/jdk1.6.0_14/bin/javac -classpath
> /opt/jdk1.6.0_14/jre/lib/plugin.jar
> (2) Create a LStest.html:
>         <head></head>
>         <body>
>             <applet archive="LStest.class" code="LStest" MAYSCRIPT></applet>
>         </body>
> (3) Copy LStest.class and LStest.html somewhere so that you can access it with
> a web browser.
> (4) Make sure you have Firefox 3 and it uses Sun JRE plugin >= 1.6u10. I
> recommend to enable the Java console by default using
> /opt/jdk1.6.0_14/bin/ControlPanel because when its open you can still use it
> even in case the browser is frozen.
> (5) Try to load LStest.html with Adblock Plus enabled and then with Adblock
> Plus disabled. In case Adblock is enabled loading LStest.html will freeze the
> browser in most cases. Last output in the console is then:
> init
> liveconnect: the url of the applet is and the
> permission is = false
Attached file JAR file for testcase
Attached file Testcase
I'm the original reporter of the problem. I just noticed that the same hangs occur even with adblock disabled in case multiple applets on the page do LiveConnect operations at the same time but with lower frequency. I stumbled over a blog entry talking about threading issues:

but actually it did not help to synchronize the LiveConnect operations in the applets. For this I have not yet a simple test case but I just want to mention it. Maybe it helps finding the bug.
My comment regarding multiple applets is probably not true. The reason why it hangs in this scenario was that I had also JavaScript-to-Java calls in the code.

Now this is an important fact because when I modify the test-case a bit and call
a function in the Java applet from JavaScript for example by an onload handler:

<body onload="document.applets[0].jsToJava()">

then it hangs even without the Adblock Plus extension. My guess is that Adblock Plus implicitly triggers a JavaScript-to-Java call in the browser which then causes the hang.

Citing from :

  "2.4 Java Object Operations and the Applet Lifecycle

   The first JavaScript-to-Java call is allowed against a particular applet
   instance when either:

     * Applet.init() completes for that particular applet instance, or
     * the applet makes its first Java-to-JavaScript call. 

   The Java Plug-In guarantees that if the browser attempts to make a
   JavaScript-to-Java call against a particular applet, the browser will wait,
   with control not returning to the JavaScript engine, until one of the
   following occurs:

     1. Applet.init() completes for that particular applet instance
     2. The applet makes its first Java-to-JavaScript call
     3. An error occurs during initialization of the applet 

   For cases (1) and (2) above, once either of these conditions is satisfied,
   all subsequent JavaScript-to-Java calls go through immediately for that
   applet instance. For case (3), an exception will be raised in the JavaScript
   engine for the initial and any subsequent JavaScript-to-Java calls against
   that applet instance."

This means that it should not be necessary to wait until the applet has been initialized before calling into it from JavaScript because the browser will wait until the applet has been initialized or made itself a Java-to-JavaScript call. But the latter unfortunately seems to deadlock.

Avoiding any Java-to-JavaScript calls until a JavaScript-to-Java call seems to be a workaround but this requires design changes to Java applets that use LiveScript during the initialization phase. I think the original scenario should work too as documented.
A fellow just noted that the "new plugin architecture" is implemented in a different plugin called jre/lib/i386/ Using it instead of the fixes the hang issues.

Nevertheless the hanging issue with the legacy - but widely used - plugin is a bug either in the mozilla code base or the JRE.
Same crash (and 100% cpu) problem here.
[Firefox 3.5.1, Java 1.6.0_14, Crux Linux 2.5]

Comment #6 did the trick.
Issue SOLVED, here.

Thanks, Ronald Wahl.
Same crash (and 100% cpu) problem here, but Comment #6 didn't solve the issue.

Firefox 3.5.2, Java 1.6.0_15-b03, Fedora 11.

Tested on facebook image uploader.
Hangs also on Microsoft livemeeting and our company's travel expense reporting tool (java application)
I'm marking this bug as WONTFIX per bug #1269807.

For more information see -
Closed: 7 years ago
Resolution: --- → WONTFIX
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.