JSException: Failure to evaluate callbackApplet

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Embed gwt app into iframe in some other app
2. change the content of the iframe from the parent app (ie tabs that change 
the source of the iframe from one gwt app to other)
3. Use IE9

What is the expected output? What do you see instead?
Expected that applet will run as always. Insted sometimes I get exception

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(PinMailerApp
let.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

What version of the product are you using? On what operating system?
GtwAI 0.3 release, Windows IE9

Please provide any additional information below.
Bug does not show up on any consistent manner, sometimes after just 2 iframe 
content switches, sometimes after 200. But when it shows up only solution to 
make it work is to restart the browser.

Any workarounds or tips are welcome.

Original issue reported on code.google.com by Nadirow...@gmail.com on 13 Dec 2013 at 9:09

[GoogleCodeExporter]

As far as I know, no significant testing has been performed with GwtAI 0.3 
where the GWT application is in an iframe.  Also, I do not believe that 
significant testing has been done using IE9.  I do 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.  Lets say 
that the applet was either in the middle of doing something, or waiting for an 
event to occur when the iframe's source gets changed.  Then, the applet either 
finishes what it was doing, or the event it was waiting for occurs and the 
applet tries to use the callback.  If the browser has already cleaned up the 
old JavaScript context, because it is no longer associated to the iframe, then 
the callback will fail.  If this is the cause, then I suppose you could try 
adding a method to your applet which may be called to tell the applet to stop 
what it is doing before you change the source of the iframe.

Right now, I do not have a lot of free time to try to reproduce this problem to 
verify that my suspicions are correct, and when I do get time, my focus has 
been on branch_0.4.1.  So, if you, or anyone else is able to verify that it is 
the case that the JavaScript object the callback references is being cleaned up 
before the applet calls the callback, it would be greatly appreciated.

Thank you,

Drossen

Original comment by dros...@live.com on 31 Dec 2013 at 4:19

[GoogleCodeExporter]

The more I think about this, the more I am convinced that the problem is 
related to the JavaScript context being cleaned up before the Java applet calls 
the callback.  The question I keep asking myself is "why would it work 
sometimes, after changing the source of the iframe, but not always?"  The 
answer, I believe, is because the old JavaScript context does not necessarily 
get cleaned up right away.  The JavaScript engine has a garbage collector which 
runs periodically.  If the garbage collector DOES NOT run between the time the 
iframe's source is changed and the time the applet calls the callback, then no 
problems will occur, because the JavaScript object being referenced will still 
be available.  However, if the JavaScript engine's garbage collector DOES run 
after the iframe's source is changed, but BEFORE the applet calls the callback, 
then a JSException will occur because the JavaScript object being referenced 
will no longer exist.  The question I then ask myself is "why would the 
JavaScript garbage collector clean up that JavaScript object when the applet 
still holds a reference to it?"  The answer is because the JavaScript engine 
DOES NOT know about what is going on inside the Java Virtual Machine, which the 
applet is running in, and therefore DOES NOT know that there is still a 
reference to that JavaScript object.  Thus, the JavaScript engine's garbage 
collector will clean up the objects associated with any JavaScript contexts 
which are no longer associated with a DOM object.  One way to think of it is 
that any references a Java applet has to JavaScript objects are WEAK 
references, and therefore the objects referred to may get garbage collected 
once no hard references exist to the JavaScript context in which the JavaScript 
objects the applet references belong.

The following are suggested solutions to developers having this problem:

    1) 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 object after the iframe's source has been changed.  This solution
       will have the smaller memory footprint, out of the solutions I am presenting,
       but would require developers to always remember to stop their applets whenever
       they change the source of an iframe.

    OR

    2) Instead of reusing the same iframe, have multiple iframes which are all
       hidden, except for 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 do not believe this problem to be an issue with GWTAI.  Therefore, I will add 
an entry to the FAQ containing an explanation to the probable cause of the 
problem and close out this issue.

Thank you,

Drossen

Original comment by dros...@live.com on 6 Jan 2014 at 2:52

• Changed state: Done