Developer Tools in IE Hides Bug

The other day I put some code on our UAT (User Acceptance Testing) server so that some new code could be tested and I started received a very alarming bug that one of the pages simply didn’t work at all. The page was in an administration section of the website and relied heavily on JavaScript even just to display the initial content (which was retrieved via an AJAX request)

As a quick initial smoke test I loaded the page up on my machine and it was working using my developer build. Then I looked at the page on the UAT server in case it was some quirk of the build and it was also working. I then noticed that the person doing the tests was running IE, so I though it might be a browser issue, so I loaded the page from the UAT server up again, this time using IE and it was still working on my machine.

Since it was lucky enough that the particular section was an admin section (which would be used only in-house) the people testing it were not actual customers of ours so I could walk over to their desk and ask for a demonstration in case there was some quirky step that had to be undertaken. When the page was loaded up I immediately saw that it didn’t work.

Being a developer my first instinct was to open up the Developer Tools in IE and have a look at what was happening. So I hit F12 and the reloaded the page…. and it started to work!  It worked with the Developer tools turned on!

I couldn’t fathom that out. What was so different about Internet Explorer when the Developer Tools were turned off so I started going through the various things that IE was showing me in the developer tools, stepping through code and watching the AJAX request go out then come back with data and start to process that data…. And then I noticed it. There was a line that said:

console.log("blah… blah…. blah…");

On a regular user’s machine the Developer Tools are never running, so it never has a console, so the JavaScript just broke.

Demonstrating the bug

How you you try this out? I’ve written a small demo to show what I mean. Obviously, you need to open it in Internet Explorer. I’ve tried it in IE 8.

If you have already opened the Developer Tools previously then you may find that they open automatically, which makes any testing impossible. Shutting them down and restarting IE doesn’t help. You have to go in to the registry and manually disable the developer tools.

To disable the Developer Tools in Internet Explorer you need to edit the system registry. Open up regedit and navigate to HKCU\Software\Microsoft\Internet Explorer\IEDevTools then create a DWORD called Disabled and give it the value of 1.

Once you have disabled the Developer Tools you’ll see that the page displays the text:

This paragraph has been update by javascript.

This paragraph is not yet updated by javascript, and if the Developer Tools are not present, it won’t update.

And a small warning triangle appears in the status bar of IE. Double clicking on the warning triangle brings up a dialog with some error information that looks like this:

To re-enable the Developer Tools simply delete that setting and restart Internet Explorer, press F12 to bring up the developer tools then open the demonstration page again.

Now the text displayed on the page reads:

This paragraph has been update by javascript.

This paragraph has also been updated by javascript, indicating the developer tools are present

Preventing this bug

Obviously running functions on the console object is not all that desirable in a production system so the idea is to remove all those calls so that IE won’t crash. If you find that is impractical you could put in some JavaScript before other JavaScript is run such as the following:

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

This will ensure that if a console object does not exist then one is created and a dummy function is attached to it. If you use other functions on the console object then you should add them also in a similar way.

The above demonstration has been updated to show this console “protection” in action.


Browser wars

Every so often I update my chart of the technologies people use to view my blog. The last time was back in October last year, and the chart as it looks now is very interesting. The three major browsers (Internet Explorer, Fire Fox and Chrome) are now converging at around 30% share each. Other browsers such as Opera and Safari don’t get much of a look in. However, it does look like I’ll shortly have to start noting down one or two mobile browsers distinctly. Currently mobile browsers are all lumped into the “Other” category.

Meanwhile, on the operating system front Windows XP continues to slowly ebb away. However, the fact that 30% of the visits to my blog are from a Windows XP machine is still painful to see. Vista users are also dying away and are down to about 6% now. At its current rate of decline there will be more Mac users visiting my blog by the turn of the year.

Google Analytics also has a facility to record page load times, however it is currently only reporting from Internet Explorer and Chrome at the moment. That coupled with only 3 months of data so far doesn’t make for very interesting trend watching. However, in a future update I’m sure I’ll add page load times.

Tip of the day: IE Quirks Mode Vs. Standards Mode

If you are setting the DOCTYPE declaration in an HTML page to define the standard your page complies with ensure that you don’t put anything before that DOCTYPE declaration.

Some browsers will ignore comments and such like before the DOCTYPE declaration but IE doesn’t and if there is a comment it will then ignore the DOCTYPE which then puts your browser into Quirks Mode (and that can screw up the rendering of your page)

So, if I put this at the top of the document:

<!-- This will trigger IE into quirks mode -->

Then quirks mode will be rendered.

However, if I put the comment after the DOCTYPE everthing is fine, like this:

<!-- This won't trigger IE into quirks mode as the DOCTYPE is first -->