EVALUATION
Thanks to analysis from ###@###.###, it turns out this is very
similar to an earlier bug around dynamic generation of the applet tag
in IE, 4751259, and it was possible to write a regression test for
this bug.
|
|
|
EVALUATION
Reproducible on current build. Likely related to introduction of legacy applet lifecycle support in b09, which mandated the fetching of the document base in IE. Exception on the browser side is the following:
Exception in thread "main" java.lang.IllegalStateException: Can not fetch the document base before SetClientSite is called
at sun.plugin2.main.server.IExplorerPlugin.getDocumentBase(IExplorerPlugin.java:326)
at sun.plugin2.main.server.JVMInstance.startApplet(JVMInstance.java:212)
at sun.plugin2.main.server.JVMManager.startAppletImpl(JVMManager.java:237)
at sun.plugin2.main.server.JVMManager.startApplet(JVMManager.java:119)
at sun.plugin2.main.server.JVMManager.startApplet(JVMManager.java:92)
at sun.plugin2.main.server.IExplorerPlugin.maybeStartApplet(IExplorerPlugin.java:875)
at sun.plugin2.main.server.IExplorerPlugin.SetObjectRects(IExplorerPlugin.java:223)
|
|
|
EVALUATION
The failure is likely unrelated to the changes made for the legacy applet lifecycle. The calls to the methods on our ActiveX control are made in a much different order than we have seen for any other applet so far. The applet also works correctly in Firefox 3 with the new plug-in. Continuing to investigate.
|
|
|
EVALUATION
The web pages containing these applets had a strange initialization
sequence causing our ActiveX control to be deactivated and
reactivated. We were eagerly releasing our handle to the client site
which we received in SetClientSite during InPlaceDeactivate. It turns
out that the semantically correct thing to do (for which we already
had code) is to only do this when SetClientSite is called again with a
null site. Removed the incorrect code from InPlaceDeactivate. This
fixes the problems both with the VRX Studios hotel applets as well as
the game applets from IWon.com.
|
|
|