Unexpected restart on IE9

Question

I am working on a Java applet and running into an issue on IE9. In our design applet would be added and removed from the document when a particular tab is selected/deselected.

1) When the tab is slected, applet shows up fine. in java console, i see following messages:

basic: Added progress listener
 basic: Plugin2ClassLoader.addURL parent called for XXX

basic: Applet initialized
 basic: Starting applet

basic: Applet made visible
 basic: Applet started
 basic: Told clients applet is started

2) When tab is deselected: In java console

basic: Starting applet teardown

basic: Finished applet teardown
 basic: Removed progress listener: 

Immediately followed by (Not sure who and why did the applet start up again)

basic: Added progress listener:

basic: Plugin2ClassLoader.addURL parent called for

basic: Applet loaded.

basic: Applet resized and added to parent container

basic: PERF: AppletExecutionRunnable - applet.init() BEGIN ; jvmLaunch dt 106964 us, pluginInit dt 45402059 us, TotalTime: 45509023 us

basic: Applet initialized

basic: Starting applet

basic: completed perf rollup

This same applet works fine when Document Mode is switched to IE8. Also, Firefox works fine too...

BTW, i'm using following version of JRE

Version: 7.0.150.3

Any ideas why this unexpected restart of applet?

Answer 1

(I also came across your MSDN TechNet Forum message on the same issue.)

I just hit your issue with a project doing something similar: we were injecting and removing applets from the DOM of a single-page application, where we couldn't expect to keep injecting them for ever and consume resources, and were it proved too difficult to deal with all the quirks of the browsers we support when it came to keeping the applets alive for a long duration of time (days) in a tab. As the management of the applet lifecycle is not really enforced and varies from browser to browser, some would kill them off and using "short-lived" applets proved overall "safer" and "simpler".

That is, except for 2 issues in IE9:

• if not forcing IE9 to use a separate JVM for each applet, it would crash under certain configurations when trying to re-inject and re-execute the applet.
• after a Windows Update that I suspect to be February 12's KB2792100 addressing the security bulletin MS13-009 , the one we currently deal with.

Note that I am not entirely sure what triggers IE9 to behave like this, but I would suspect an internal race condition when removing the applet (or a strange safeguard that would assume that removing it is a mistake, except it doesn't seem to always bother it).

Also, for both issues I mention, I've found at least ONE workstation where the problem didn't occur, without being to determine why (hardware config, win + ie version, java plugin version...). All my colleagues' workstations and our test servers would fail consistently, except for my machine (which made debugging all the more fun).

Workaround

The way we worked around it is unsatisfying, but we make do with that for now: we have a special case for IE9. Hopefully IE10 is bug free, and IE8 or even IE9 in IE8 mode or as mentioned in your MSDN post IE9 in a different compatibility mode do not seem to trigger the problem.

So for good ol' IE9, what we do is indeed use a more traditional long-lived applet, and use JS to Java communication to make it do what we want on demand, and we skip the DOM removal part... Which means we might need to notify users they may occasionally need to refresh their tab or something like that if the java plugin doesn't behave or if IE decides to kill the applet.

Hopefully, a next update won't make it worse.

Alternate Workaround

I also found something rather odd. Normally, we were removing the applet from the DOM when it was done : upon the completion of its task, it would trigger a JS call back, which in turn would remove the applet from the parent. And, just in case, we'd also remove any existing applet before injecting a new one, in case the previous one wouldn't have been removed correctly.

Now both of these would fail, since a few weeks.

But I noticed that I could inject the applet, and then start a repeated function with setInterval() and have it check regularly for the applet, and then remove the applet as soon as it would see it be available. Strangely enough, using this approach the bug wouldn't occur!!

However, I didn't go down this route as:

• I don't really like adding this sort of weird timers for ad-hoc reasons and risk them never being discarded,
• I'm afraid that the applet could get removed before it's done with its work and terminate early. Doesn't seem to be the case, but as that sort of stuff is rather "unspecified", I'd rather leave it alone.

Other things you can try

You could try using an <object> tag instead of an <applet> tag. That's actually recommended for IE, but we couldn't do that as we want the applet to auto-start when injected, and for some reason IE8 (the only one from all the frigging browsers we support) would refuse to auto-start an applet injected after the page load. So you could check if that works, and if it does and you don't need IE8 you might be golden (or instead of a special case like the above, you could use different tags for IE8 and IE9).

But I haven't had the chance to try (yet).

Best of luck.