Workaround for KB912945 ActiveX Patch

When using internet explorer you may see a message which reads "click to activate and use this control" or "Press ENTER or SPACE to activate this control". These messages appear because of a patent dispute between Eolas Technologies and Microsoft which Eolas won after several years of court battles. The patent covered automatic activation of embedded controls in web pages. It affects Flash, Java Applets, embedded acrobat readers, SVG inserts, streaming video and any other type of embedded control that the user interacts with. All cases use one of three HTML tags: APPLET, OBJECT or EMBED.

Rather than negotiate a license agreement with Eolas, Microsoft have issued a patch (KB912945) for Internet Explorer 6 that disables automatic activation of the controls. With the patch in place the user sees a message on the page requesting activation of the control by clicking with the mouse or pressing a key. The controls will run without the activation but the user will not be able to interact with them. E.g. they cannot use scrollbars or other parts of the control. all mouse click, mouseover and keyboard interaction with the control is affected. In practice the user usually will not understand the need to activate the control because it is not always obvious that they are there. As an example, many adverts are written in Flash and require the user to click on them to go to the advertised page. With the KB912945 patch the first click will seem not to work because it is required to activate the Flash control. The next click will have the desired effect, if the user ever realises it.

Since Flash adverts are not very popular with users, this may not be such a terrible thing from some peoples point of view, but ActiveX controls of other types are affected so it really is a significant problem to web users and developers alike.

Many words have been said about the moral side of this case. Some people argue that Eolas are morally wrong to enforce their "speculative" patent for large sums of money without having done much themselves with the patent. Others might counter that this is the way US patent law works and Microsoft should be more willing to negotiate a license. After all, they have benefited from the same patent laws for protection of their own ideas many times over. Whatever side you take, the result remains the same. It is the web developers and users who will be hit.

It has been ruled that the Eolas patent does not apply if the ActiveX control is activated by any means external to the page, and that does not have to be the page user. The control can be activated by JavaScript calls running from an external file. This loophole has been built into the KB91294 patch so that web developers can work around the problem. The idea is that the HTML for the control should be generated as the page is loaded using dynamic HTML from an external page and then it will work as before. This is what Microsoft have recommended web developers to do.

The Microsoft Workaround

As an example of how it can work, here is the Sun clock applet with and without the workaround. The interactive feature of this clock is that if you click on it you are taken to another page. If you are using Internet Explorer with the KB912945 patch you should find that the first clock needs activating first. This means two clicks will take you to the page. The second version has the workaround in place and works with one click as normal.

Normal Applet HTML
<applet code="JavaClock.class" 
        width="150" 
        height="150">
	<param  name="link"    value="back.html">
</applet>
Applet With Microsoft Workaround
<!-- the script is used to workaround the KB912945 patch -->
<script src="write_control.js" language="JavaScript"></script>
<script language="JavaScript"> write_control( '\
<applet code="JavaClock.class"\
        width="150"\
        height="150">\
')</script>
	<param  name="link"    value="back.html">
</applet>

The contents of the external JavaScript file write_control.js are as follows

 function write_control( text ) {
   document.write(text);
 }

Notice from this example that it is not necessary to write the params or the closing applet tag from the JavaScript. The opening applet tag and its attributes is sufficient. This method should work in any browser that runs JavaScript and Java applets and a similar technique works with object and embed tags.

The Quick Comment Workaround

The Microsoft workaround above can be awkward to implement, e.g. if there are many cases to deal with, or if the HTML is dynamically generated in the web server. Some webmasters have therefore looked for trick ways to workaround the patch. The trouble is that most of the ones suggested fail to work for some versions of browser or Java JVM. For example, some code writers suggest getting the HTML of the applet tags on the page using the innerHTML method and then overwriting them. With the Sun JVMs this does not work when the applet has params. Another method is to put noscript tags around the applet and get the innerHTML of that. Sadly, the innerHTML method on the latest versions of IE7 does not work for the noscript tag. Extensive testing has found only one method that does actually work. It uses the microsoft comment tag. Here is one final example of the clock showing it in use.

Applet with Comment Workaround
<!-- the comment and script is used to workaround the KB912945 patch -->
<!--[if gte IE 6]> <comment id="to_be_rewritten"> <![endif]-->
<applet code="JavaClock.class" 
        width="150" 
        height="150">
	<param  name="link"    value="back.html">
</applet>
</comment><script language="Javascript" src="rewrite_comment.js"></script>

The contents of the external JavaScript file rewrite_comment.js are as follows

var elem = document.getElementById("to_be_rewritten");
document.write(elem.innerHTML);

The surrounding comment and script lines (shown in bold) can either be placed around the applet/object/embed element, or they can be placed around the whole HTML just inside the body tags. Of course this can fail to work if the page already uses these comment tags but that is rare and easily changed. Once this is done the only remaining impact is that the page load will be slowed down by the need to fetch the extra JavaScript code. There is no way to avoid that hit.