This first issue (checking for javaEnabled) was fixed in Internet Explorer 8 beta 2. The remaining issue (setting styles) was fixed in Internet Explorer 9.
No two browsers have exactly the same JavaScript implementation. Most browsers offer a few extensions, and some browsers have implemented the extensions of the others, sometimes because they are incredibly useful, and sometimes just to avoid errors on badly written pages.
Before using one of these extensions, or before using a method that is not well supported, a support detect (sometimes
called an object detect) will help to avoid errors. This is the correct way to do things, and it is perfectly valid. Being
able to check for method support in this way is required by the ECMA (JavaScript core) specification:
if( document.getElementById ) {
//use document.getElementById
}
However, IE being what IE is, it does not always get this right. It will produce errors if you try to use this to check for
methods of the navigator object, such as
if( navigator.toString ) {
or
if( navigator.javaEnabled ) {
or
if( navigator.taintEnabled ) {
The first and second of these are supported by virtualy all browsers (and are in the original JavaScript specification),
but the third is not supported by some. Thankfully it is not really used any more, so errors are very rare.
But it goes further than that. Debugging scripts often loop through objects, looking for properties and getting string
representations of them. In Internet Explorer 7, things got worse. It also produces errors when you attempt to access the
opsProfile and userProfile properties. That might be forgivable, since there is no reason to use them in a script, but
unfortunately, those properties are presented when iterating over the navigator object with a for...in loop. So this
simple piece of debugging code now earns an error in IE 7, and causes the script to abort:
var s = '';
for(var i in navigator) {
s += i + ' ' + navigator[i] + '\n';
}
alert(s);
More common though is window.external. This is used to add bookmarks in IE and iCab. It also provides other features in IE, but these are not supported in iCab. Checking for any methods of this object causes errors in IE, but it is necessary to avoid errors in iCab. Take a guess which users will lose out. No doubt there are other cases of IE producing errors like this, (like the way earlier versions produced errors if you checked for document.all.tags, even though they supported it, and the way that all versions will produce errors if you check for navigator.__ice_version while the window is closing [using onunload]).
This is not the only case of IE producing errors in valid scripts. It will also produce errors if you apply a value that
it doesn't understand to style that it does understand. Even if that value is in fact valid.
someElement.style.display = 'table-cell';
These errors are completely uncalled for. I'm sure they thought it would help us to work out if the property was accepted
or not, but actually all that happens is that IE users get errors. Very useful. I'm sure.
Demo: Click here to see if your browser allows us to check if Java is enabled, and click here to change the display style of this paragraph to 'a-value-this-browser-does-not-know'.
Workaround: Wrap code that may produce errors inside the try...catch control structure, and hope that none of your visitors are using an old browser that does not support it.