Reynholm Industries

Making your website fully compatible with Internet Explorer can be a really nightmare, but if you are more or less a newbie to this front end effort can be a headache. As some of you know, recently I’ve been involved on creating a front end using nice javascript technologies, have to say I really rediscovered the power of this part of the ecosystem, however I’ve to provide support for IE9, and sometimes I find interesting stuff.

One of this “interesting” behaviour is how Internet Explorer manage the console object, for the ones of you who still don’t know it, console is a useful add-on on to the DOM spec. So as you can guess every one is doing whatever he/she wants with this object.

Lets go to our use case here, how Internet Explorer manages that utility. The main idea is that the console object is just available when the Web Developer Tools are open, and right after that, but if your code makes usage of this object, and you where in “normal mode”, so no console exposed, the code will fail and return undefined.

At StackOverflow there is a very good explanation of that problem.

In Internet Explorer 9 (and 8), the console object is only exposed when the developer tools are opened for a particular tab. If you hide the developer tools window for that tab, the console object remains exposed for each page you navigate to. If you open a new tab, you must also open the developer tools for that tab in order for the console object to be exposed.

The console object is not part of any standard and is an extension to the Document Object Model. Like other DOM objects, it is considered a host object and is not required to inherit from Object, nor its methods from Function, like native ECMAScript functions and objects do. This is the reasonapply and call are undefined on those methods. In IE 9, most DOM objects were improved to inherit from native ECMAScript types. As the developer tools are considered an extension to IE (albeit, a built-in extension), they clearly didn’t receive the same improvements as the rest of the DOM.

This can provoke interesting problems, so take care of using a proper logging library, mocking the console object, whatever you think appropriately for your application.

List of useful tools for logging in web applications:

• log4javascript : Is a JavaScript logging framework based on the Java logging framework log4j.
• Log4js : The Logging Framework for JavaScript.
• Blackbird: A dead-simple way to log messages in JavaScript and an attractive console to view and filter them.

or simple use a pice of code like, so mock or have a simple cross browser solution:

if (!window.console) window.console = {};
if (!window.console.log) window.console.log = function () { };

here you can custom as much as you want, or need, the logging capabilities of your library.

The last, but not the lest, I added a new repository at GitHub with some demo code, so you can play and see whats up with your Internet Explorer version.

• The Console playground: A console playground for logging in javascript.

Have fun!

Related posts:

1. Software Engineering met’s Javascript world (more or less)