JSException: Failure to evaluate callbackApplet

[Adam Andrzejewski]

I have an issue when using aplet in IE9.
My app contains multiple gwt applications that are displayed in iframes depending on the tab in the main page. In one of the tabs I have the applet. Sometimes when I switch from one tab to another (which makes the restart of gwt apps) I get such exception when applet is loading

basic: Applet initialized
basic: Starting applet
basic: completed perf rollup
netscape.javascript.JSException: Failure to evaluate callbackApplet("IMyAppletImpl1", "U1RBUlRFRA==", "java.lang.String");
at sun.plugin2.main.client.MessagePassingJSObject.newJSException(Unknown Source)
at sun.plugin2.main.client.MessagePassingJSObject.waitForReply(Unknown Source)
at sun.plugin2.main.client.MessagePassingJSObject.eval(Unknown Source)
at com.google.gwt.gwtai.applet.util.AppletUtil.eval(AppletUtil.java:140)
at com.google.gwt.gwtai.applet.util.AppletUtil.callback(AppletUtil.java:133)
at com.google.gwt.gwtai.applet.util.AppletUtil.callback(AppletUtil.java:113)
at com.gemalto.dexxis.framework.pinmailer.applet.PinMailerApplet.start(PinMailerApplet.java:33)
at com.sun.deploy.uitoolkit.impl.awt.AWTAppletAdapter.start(Unknown Source)
at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Ignored exception: netscape.javascript.JSException: Failure to evaluate callbackApplet("IMyAppletImpl1", "U1RBUlRFRA==", "java.lang.String");
basic: Dialog type is not candidate for embedding
basic: Removed progress listener: sun.plugin.util.ProgressMonitorAdapter@2e86ae77
security: Reset deny session certificate store

Any ideas? It's not a permament issue, but when it happens, only solution is to restart the browser. Then it works for some time, and for unknown reasons it blows up...

[Drossen Koren]

I know that Microsoft did introduce some changes to IE9 in how iframes are handled (http://msdn.microsoft.com/en-us/library/gg622929%28v=VS.85%29.aspx?ppud=4).  However, it does not sound like you are removing the iframe from the DOM, so I do not believe that those changes are the cause of the problem. Instead, I think it may be caused by the fact that the Java Virtual Machine, running the Applet, runs in a different thread than the browser, and the fact that a new JavaScript context is created when the iframe's source is changed.

Remember that the JavaScript engine does not know anything about what is going on inside the Java Virtual Machine, and so it has no way of knowing that a Java applet still has a reference to a JavaScript object. Also, keep in mind that a new JavaScript context is created when the iframe's source is changed, making the old context available for garbage collection. If the Java applet uses the callback after the iframe's source has been changed, but BEFORE the JavaScript engine's garbage collector runs, then the call will be successful, because the JavaScript object will still exist. However, if the Java applet tries to use the callback after the iframe's source has been changed, AND AFTER the JavaScript engine's garbage collector runs, then the call will result in the JSException being thrown, because the JavaScript object will no longer exist. Think of any references a Java applet has to JavaScript objects as being WEAK references, from the view point of the JavaScript engine, and may be cleaned up once the JavaScript engine sees no more hard references to the context to which the JavaScript objects belong. And thus, since there is no guarantee on when the JavaScript engine's garbage collector runs, calls from Java applets to JavaScript callbacks will sometimes succeed, and will sometimes fail after changing an iframe's source.  In other words, the calls a Java applet make to a JavaScript callback will continue to succeed after changing an iframe's source until the JavaScript engine's garbage collector runs, after which, the calls will fail and result in a JSException.

If the Java applet is running inside an iframe before changing the iframe's context, there is no guarantee that the JVM instance running the applet will be cleaned up before the JavaScript context is cleaned up when the iframe's source is changed.  As a result, your applet could still be running in the background, even after the old JavaScript context has been garbage collected.

The following are suggested solutions to developers having this problem:

• Before changing the source of an iframe, make sure to stop whatever your Java applets are doing, to ensure that they will not attempt to use references to JavaScript objects after the iframe's source has been changed. This solution will have the smaller memory footprint, out of the solutions presented here, but would require developers to always remember to stop their applets whenever they change the source of an iframe.

      OR

• Instead of reusing the same iframe, have multiple iframes, hiding all but the one whose source is to be displayed. Just remember that this solution will have a higher memory footprint, and may not be the best choice when there are a lot of iframes needed, and/or when the total size of the contents to be loaded is high for the sites being embedded within the iframes.

I hope this explains what may be happening, and gives you some ideas on how to work around the problem.

Thank you,

Drossen