When jQuery returns failed in IE - and how it's probably resolved
In web development, I love facing unexpected problems I haven’t seen before. It’s an excellent situation to learn new things. And the moment right after I’ve found a solution – it’s a perfect moment. But when I can’t find a solution, no matter how hard I try, and especially when I can’t find anything from Google that could help me.. well, I get very frustrated. In this brief article, I’ll go through one problematic situation that really got me frustrated. Plus, this hopefully can be found via Google and therefore works as a solution to anyone who’s facing a same problem.
Last week at work, I encountered a very peculiar problem in Internet Explorer. There were several IE-related bugs reported in a certain part of the service. However, I couldn’t reproduce them and I expected these bugs had been fixed during other updates in the code.. ..until it suddenly happened. All the tested versions of IE’s (6, 7, 8) started reporting either error “failed” or “unexpected error”, pointing to jQuery’s code. And there worst part was that error occurred occasionally, although nothing was changed. In this case, there’s jQuery 1.3.2 in use. Error message didn’t help and the line it was pointing to, belonged to a internal / helper function into jQuery. At first, errors disappeared after some fixes I expected to resolve the situation. But, like I mentioned earlier: these errors were occasional. I didn’t have anything that could have helped me at least a little on tracking this problem (later I found not even unit tests would’ve solved this – although it’s not an argument why I didn’t have unit testing for javascript). So, my only choice was trying to isolate the problem function by function, line by line. Ultimately I found that all the errors were caused by event handler bindings made with function $.fn.live(). I couldn’t blame the selectors being too unprecise, although I reduced the amount of troublemakers by fine-tuning them. In addition, I found that wrapping them in setTimeout() with small delay would have possibly fixed the problem. Also, IE6 had the most problems, while IE7 started to feel stable. Most likely there was something going on with perfomance. However, after all this I wasn’t in a mood to expect these problems were completely solved. So I ended up binding event handlers with $.fn.bind() whenever something was dynamically added. It meant more lines of code, but it also meant that no errors were occurred ever again. The point of this article can be put in one sentence: if you receive an error with message “failed” or “unexpected error” from jQuery and this happens only in Internet Explorer, comment out every possible live() binding and try again.
It’s somewhat usual to leave the testing with Internet Explorer until the end of the project. This is quite acceptable when you’re dealing mainly with layout issues. But when you’re building a web application with loads of features, there are several issues to struggle with: constant debugging, client-side performance, proprietary bugs and so on. However, getting your hands dirty with IE doesn’t always feel as comfortable as with other browsers. In this article, I’m going to list and review different set of tools, which will help you and make your debugging and testing process in Internet Explorer much more enjoyable.
This article is a general overview of different tools and resources that are available for IE. Unfortunately it’s not providing any detailed information on how to use these tools properly. But I still hope this article offers you a good start. This article is split into following topics:
  1. Browser Packages – different IE browser packages
  2. General Debugging Tools – most common debugging tools
  3. Performance Testing Tools – excellent tools for performance testing
  4. Other Resources – additional resources worth of checking

Browser Packages

Browser Packages The first step is to install all the common versions of Internet Explorer (IE6, IE7, IE8). There are several options available and I’ll review four of them.

Utilu IE Collection

My personal recommendation is Utilu IE Collection. Don’t be scared, it’s very reliable (despite the appearance of website). Utilu IE Collection contains multiple IE versions, which are standalone so they can be used at the same time. The main reason I recommend this package is because the browsers it provides are very stable. Utilu IE Collection also includes the Internet Explorer Developer Toolbar.

BrowserSeal.BrowserPack

If you’re in need of older versions of other browsers, I recommend installing BrowserSeal.BrowserPack. It uses the Internet Explorer Collection mentioned above, but in addition it allows to install browsers like Safari 3 and Opera 9. Browsers provided in BrowserSeal.BrowserPack are very stable and I haven’t encountered any problems.

IETester

IETester contains several advantages compared to other packages, like opening different versions of IE into tabs. IETester is provided by DebugBar and they’re also responsible for providing excellent debugging tools like DebugBar and Companion.js (both reviewed later in this article). However, IETester still (v0.4.2) feels quite unstable and I’ve encountered some contradictions while debugging. But I’m quite convinced these kind of issues gets fixed sooner or later and therefore keep IETester in my armament.

Microsoft Expression Web SuperPreview

Microsoft Expression Web SuperPreview is a stand-alone application and part of Microsoft Expression Web 3 product. Mainly, it can be used for viewing the pages side by side on IE6, IE7 and IE8. In my opinion, this application doesn’t provide any value for debugging and testing. It’s targetted for web design, offering the possibility for swift visual overviews and comparing layouts between different IE versions.

General debugging tools

General Debugging I’m quite certain you’re using Firebug on Firefox. And maybe you’re aware of Firebug Lite and already using it. Still, there’s a good chance that you’re wondering how to debug in Internet Explorer.

Firebug Lite

You might be already aware of Firebug Lite. If not, read further. Firebug Lite is a JavaScript file you can insert into your pages to simulate some Firebug features in other browser than Firefox. It doesn’t affect or interfere with HTML elements that aren’t created by itself. I have to say I’m not that big fan of Firebug Lite. First of all, many core features of console are already implemented in other browsers. Second, it’s not always working properly. I’ve personally encountered some problems especially with IE and therefore I never count solely on it. Still, it’s a must. Go ahead and start using it, if you still haven’t.

IE Developer Toolbar

You may be familiar with Developer Tools for IE8. Well, IE Developer Toolbar is practically the same tool for IE6 and IE7. And it’s provided together with IE Collection by default. IE Developer Toolbar is easy to use and offers a broad set of options for general debugging. It can be compared to Web Developer add-on for Firefox.

DebugBar

All the features you’re missing from Developer Toolbar, can be found in DebugBar. In most cases, when you need to find something out of the document, this can be done with DebugBar. It’s very fast and reliable. If I had to describe DebugBar in three words, I would definitely say “it just works!”.

CompanionJS

Companion.js integrates with IE and it can be briefly described as a simplified version of Firebug. Like I mentioned before, I’m not that favor for Firebug Lite on IE, and Companion.js feels much more comfortable for basic-level console logging and error reporting. However, there are two clear disadvantages in Companion.js: 1) it doesn’t support methods like console.dir() yet, and 2) it causes occasional breakdowns with other development tools for IE.

Performance Testing Tools

Performance Testing Client-side performance testing and optimization is a practice that hasn’t “existed” very long in Web Development. I mean it hasn’t been getting a lot of attention until recently. As you might know, Internet Explorer (especially IE6) doesn’t perform as good as many other browsers. I was actually quite surprised when I started testing performance with IE that even very small things can really affect on performance. I’m reviewing couple of performance testing tools that are also possible to implement in any browser, not just in Internet Explorer.

dynaTrace AJAX

If you’re using Speed Tracer on Google Chrome, then you’re going to love dynaTrace AJAX. Like the name says, it’s meant for diagnosing and tracking AJAX and client-side scripting perfomance issues. But in addition, it offers valid tools for tracking rendering (painting) issues and network load in general. dynaTrace AJAX isn’t the easiest tool to take in proper use. I was bit troubled on how to demonstrate this tool or prove the capabilities in it. Fortunately, my colleague posted a link to an article, which solved the problem: How to Speed Up sites like vancouver2010.com by more than 50% in 5 minutes. dynaTrace’s blog contains many more resources how to use this powerful tool. Read them, install dynaTrace AJAX and tackle all those nasty perfomance issues that freezes up your Internet Explorer :)

MySpace’s Perfomance Tracker

I’d say the name of this application is a bit distracting. But MySpace’s Perfomance Tracker, or “msfast” (project home) is a browser plugin that help developers to improve their code performance by capturing and measuring possible bottlenecks on their web pages. It’s very efficient tool for tracking loading and rendering issues, and in addition, it provides the validation results either in YSlow or MySpace’s own ruleset. I had some problems when I tried to install Beta. But when I first installed the alpha version and afterwards upgraded it to the beta version, it started working properly.

JSLitmus

JSLitmus is a lightweight tool for creating ad-hoc JavaScript benchmark tests. I really recommend JSLitmus for testing performance of your Javascript in general. JSLitumus really provides additional value in Internet Explorer. As generally known, there are surprising Javascript issues that really can cause performance hit in Internet Explorer. And by creating even simple testcases, you’ll probably find the actual troublemakers.

Fiddler2

Fiddler is a Web Debugging Proxy which logs all HTTP(S) traffic. Fiddler allows you to inspect all HTTP(S) traffic, set breakpoints, and “fiddle” with incoming or outgoing data. Fiddler includes a powerful event-based scripting subsystem, and can be extended using any .NET language. To be honest, I haven’t use Fiddler a lot. Mostly because performance issues I’ve encountered related to traffic on website has always been solved with another tool (in another browser). But Fiddler really provides a good and broad insight what’s actually happening between the browser and the server and offers a worthy set for tweaking details.

Other Resources

While writing this article I encountered a tool called IEInspector. It’s chargeable, but there’s a free trial version available. I didn’t have enough time to evaluate it, but you can always give it a try. There’s also a listing at Microsoft Window’s website called Internet Explorer 8 Readiness Toolkit, which is described as a list of convenient development and test tools to help test and modify applications to run on Internet Explorer 8. There are probably other tools and resources that I’m probably not aware of. If you know good tools or resources for debugging and testing in Internet Explorer, go ahead and leave a comment.