Sunday, 23 January 2011

Why I hate debugging in Internet Explorer 8

Debugging Javascript in Internet Explorer

Now with IE 8 and it's new developer toolbar debugging Javascript should have become a lot easier. There is now no need to load up Firebug Lite to get a console or use bookmarklets to inspect the DOM or view the generated source and in theory this is all well and good.

However in practise I have found IE 8 to be so unusable that I have literally stopped using it during development unless I really have to.

When I do find myself having to test some code to ensure it works in IE I have to make a little prayer to the God of Geekdom before opening it up because I know that within the next 5 minutes I will have found myself killing the IE process within Task Manager a couple of times at the very least.

Not only does IE 8 consume a large portion of all my CPU cycles it's very ill thought out event model makes debugging any kind of DOM manipulation a very slow painful chore.

Unlike proper browsers IE's event model is single threaded which means that only one event can occur at any point in time during a pages lifetime. This is why IE has the window.event object as it holds the current event being processed at any point in time.

Many developers over the years have moaned at IE for this and have hoped that with each new release of an IE browser that they would fix this odd behaviour. However every time a new version is rolled out a lot of web developers are always bitterly disappointed because apparently Microsoft feels this quirky event model is a design feature to be enjoyed rather than a bug to be suffered and they don't seem to have any intention whatsoever of fixing it or making it DOM 2 compliant at the least.

I don't know why they cannot do what Opera does and just implement both event models. At least that way they can make all the proper web developers happy at the same time as all the sado masochists who enjoy IE development

This event model really comes into its own when you are trying to debug something using the new developer toolbar as very often you want to pipe debug messages to the console.

If you are just outputting the odd message whenever a button is clicked or form loaded then this can be okay but if you attempt to do anything that involves fast moving events such as moving elements around the page or tracking fast incrementing counters then you will soon suffer the pain that comes with waiting many minutes for the console to catch up with the browsers action.

Whereas other browsers such as Chrome or Firefox are perfectly capable of outputting lots of debug messages to the console at the same time as mousemove events are being fired IE seems to either batch them all up and spit them out when the CPU drops below 50% (which might be never) or occasionally the whole browser will just crash.

At first I thought it was just me as my work PC is not the fastest machine in the office but I have seen this problem on many other peoples computers and I have also experienced it at home on my Sony VAIO laptop.

As a test I have created the following page which can be found here:


Try it out for yourself in a couple of browsers including IE 8 and see what you think. I haven't had the chance to test IE 9 yet so I don't know if the problem is the same with that version but I would be interested to know if anyone could test this for me.

The test is simple and just includes a mousemove event which collects the current mouse co-ordinates and pipes them to the console. It does this for a number of iterations which can be set with the input box.

I have found that IE will manage when setting this counter to anything less than 100 but putting it to 1000 or above it just crashes or freezes my own browser as well as killing the CPU.

Let me know what you think of this test and whether anyone else has major issues with IE and it's console logging capabilities.

2 comments:

Pete L said...

A coworker pointed your blog post out to me today and I wanted to reach out and see if I could help.

The Internet Explorer team has been working really hard since we shipped IE8 to improve the performance, and standards implementation of Internet Explorer 9. I tried the test case you provided in an internal build of IE9, as well as in the latest Platform Preview (PP7), and am happy to report that it worked perfectly in both cases!

I did notice that the page doesn't trigger standards mode - you can do that either by providing a valid doctype including the HTML5 doctype. While that doesn't have anything to do with this issue, it may help make your testing and debugging easier for other sites, as you'll get the same behavior in IE9 (and IE8) as you do in other standards compliant browsers.

If you haven't checked out the Platform Previews yet, it's worth it to see all the work that's been done in making IE9 a modern browser! It's got great support for HTML5, CSS3 and ECMAScript 5. It's got full DOM Level 2 and 3 Event support, among many other things that I think will make your life much easier. The Platform Previews will install side by side with your existing IE installation.

As you work with Internet Explorer, we want to hear your feedback. The best way to do that is through the Connect website at http://connect.microsoft.com The IE team is actively involved there and respond to all feedback that is reported!

Thanks!
PEte

R Reid said...

Hi Pete

Thanks for commenting. It's nice to know I have some people at Microsoft reading my blog :)

It's also good to know that people from tech companies are actually listening to their customers but it's a shame that it's taken this long for IE to develop a standards compliant browser and fix the event model as the developer community has been raising these issues for a very long time now.

By the sounds of it IE 9 will be a good browser you might be able to reclaim some of that lost market share in the web dev community. Obviously in the non techies world IE still rules the roost for example on one of my own large corporate sites which has a fair few million visitors a month IE 6.0 is still the most used browser (48%) closely followed by IE 8 (16%) and then IE 7 (12%). Firefox and Chrome have just over 10% between them.

Can I ask what is going to happen about the IE proprietary event model? Are you going to do an Opera and support both your own model AND DOM 2 and DOM 3 methods so that I could add events with attachEvent OR addEventListener?

Or is IE 9 going to be a total break from the past which will only support the DOM 2 and 3 methods?

I haven't had a chance to check out IE 9 yet but once I do and it does what it says it will on the tin then you can be rest assured I will write a good article or two about it.

Also you are correct in your assertion that adding a doctype to the test page didn't affect the outcome of the test in the slightest.

Thanks for visiting.