Rick Strahl's Weblog  

Wind, waves, code and everything in between...
.NET • C# • Markdown • WPF • All Things Web
Contact   •   Articles   •   Products   •   Support   •   Advertise
Sponsored by:
Markdown Monster - The Markdown Editor for Windows

JavaScript Errors in the Mainstream

On this page:

I kept a list of a few major sites that have been bombing for me with JavaScript errors just today in the last few hours since I decided to write this up:

  • Hawaiian Airlines
  • Expedia
  • Amazon's MP3 Download Site
  • Facebook (Email app)
  • Musician's Friend Checkout site
  • Authorize.NET's Admin interface
  • American Express Bill Payment
  • Yahoo - certain news stories of the portal home page

And here are a few more non-high visibility ones (all today):

  • PInvoke.NET
  • Maui Weather Today
  • Nova Savings Bank
  • Bank of Hawaii

It's amazing to see errors so prominently in major online applications and not just in some offbeat obscure areas of Web sites. As more and more JavaScript is showing up on the client side it's inevitable that there are more errors cropping up, but it's surprising how many of these errors apparently are missed by site designers. Some errors are specific to Internet Explorer, some specific to FireFox, some happen in both, but errors there are plenty of.

I usually am curious as to what the nature of errors are and it seems there are two kinds of prominent errors:

  • Load Errors
  • DOM Elements are null

Load errors seem to occur because of timing typically. Content's not quite ready because JavaScript is accessing content that's not quite loaded yet. Other errors occur because - well - elements are just null. You look at the source and you find that this or that element that the JavaScript is referencing simply doesn't exist either because it wasn't loaded properly or because the designers simply fucked up.

Ironically most of the bogus code when I've looked at it has something to do with effects and fancy graphics arrangements in the page - shadows, popups, effects. Do we really need to have shadow code update after typing every character at the cost of a constant barrage of errors that page designers hope the browser will just eat and skip over?

But this really begs the question: Are site designers not even bothering testing at least in the two most popular browsers?

Most errors trigger in IE specifically which seems to indicate that more designers are targeting Mozilla, and starting to simply ignore IE's fucked up standard support. Maybe this is what it takes to get Microsoft to clean up IE once and for all. It used to be the other way around in that Microsoft was counting on site designers who wanted to make sure that 98% of the browsers out there work with their sites and other browsers be damned. Now it seems the tide is actually going the other way with more sites failing with IE and working with more standards compliant browsers, regardless of the fact that Microsoft still holds well over 80% of the browser share. Ironic, ain't it?

I's pretty frustrating to see so much bad Web code out there so prominently displayed for general consumption. To be fair though all of the errors I've run into are non-fatal errors. If ignored, pages continue to run apparently unencumbered. I guess that almost makes it more frustrating: what a lame piece of code it must be, if it isn't even missed if it doesn't fire? <g>

I'm railing in futility against this phenomenon because I happen to run frequently with IE and script debugging enabled. IE maddingly pops up a modal debugger dialog on every error:


If I abort the error the page usually continues to load and even work Ok despite the error, but some errors (like the one on Facebook's email message editor) apparently triggers on repeating events like a keypress or hover or mouseclick and I end up stuck on the page and have to kill IE. A modal dialog for the error is a killer in this scenario.

IE really needs a better way to deal with error handling - you have two choices: ignore errors altogether and show a completely worthless warning icon with incomplete error popup for the first error. Or you can go the full Script Debugging (Tools | Options | Advanced) route that pops up the modal blocking dialog on each error. For day to day browsing it would seem ideal to turn off script debugging, but then I use the debugger all day while working in Visual Studio for debugging my own JavaScript/Ajax code and I rarely turn off this option.

I know what you're going to say - don't use IE. Use FireFox or Opera which have better error handling and I do use FireFox most of the time. Firefox mercifully eats JavaScript errors and never throws up a modal dialog. But while  FireBug for FireFox is very useful and cool for debugging on FireFox, it doesn't always work in all scenarios for debugging especially when debugging document (top) level script code. In addition, it's often necessary to debug IE specific issues inside of IE. And if you work in VS.NET the script debugging in VS 2008 is actually useful and often easier to work through than with FireBug in deep debugging scenarios when you need to inspect lots of objects and look up the call stack. You can't completely get away from not debugging in IE after all...

But, hey maybe those fancy Web Designers skip that step - they don't test for IE right? <g>

The errors I've been seeing though are hardly specific to IE though - some also show up in FireFox although FireFox in combination with FireBug certainly makes it much nicer to review the errors with an icon in the browser's statusbar and a quick access list to jump to the errors or at the very least be aware of the errors on the page.


FireBug however doesn't let you stop on an error and step into the code at the error (even as an option) either which on occasion is useful.

In the end I use FireBug for most of my debugging, IE for IE specific debugging and some heavy debugging scenarios where I need to step through lots of code - it's a lot of back and forth and I wish I could stick to one environment but it seems that's just not possible given browser DOM differences.

Ultimately though JavaScript error handling in browsers is pretty arcane. The actual JavaScript behavior is to ignore the error and abort the current block of code that's executing, but other code that follows outside of this block will continue to execute which can often result in less than accurate results and very unpredictable behavior. Trying to track down even errors in JavaScript event code is an excercise in sleuthing supreme as you get to back step through events several levels back to see where a failure occured.

It's no wonder there's so much bad JavaScript code out there - the tools are lacking.

Plain old HTML apps may have been clanky and conservative but they just worked. Now there's a lot of crap being introduced that adds little value, except try to feed our deficit attention spans and in the process make our lives more difficult. I'm all for fancier user interfaces and making applications more interactive and easy on the eyes, but when it comes to usability my first interest is that the application works! Everything else is secondary by a long shot.

There's little we can do with other sites. But we as developers ourselves can do the best we can with our own applications and not contribute to the problem. It's not always easy because JavaScript is inherently a runtime error detection environment. Let's ensure our apps at least  don't bomb by testing at least with the two mainstream browsers. That's the least we can do for our users, no?

So, is this sort of thing happening to you as well frequently? Are you running with debugging features off or are you too suffering through dialogs and error displays on common Web pages?

Posted in HTML  JavaScript  

The Voices of Reason


February 08, 2008

# re: JavaScript Errors in the Mainstream

No offense Rick, but I get 5 seperate "Syntax Error" JavaScript error modals in IE7 when I load this very page. Perhaps a little practicing of what you preach is in order?

February 08, 2008

# re: JavaScript Errors in the Mainstream

Regarding the above, three are for "http://a.lakequincy.com/s.js" and two are for "http://pagead2.googlesyndication.com/pagead/show_ads.js"

Both files when debugged in VS2005 yield the following:


Damien Guard
February 08, 2008

# re: JavaScript Errors in the Mainstream

Firebug is the only thing I now use for JavaScript debugging - it's fantastic.

Google aren't without fault ether - Google Reader throw the following with Firefox 2 on Windows:

ul is not defined
Line 80


February 08, 2008

# re: JavaScript Errors in the Mainstream

These things drive me nuts as well and I often wonder how so many of them seem to be missed. www.washingtonpost.com drives me crazy. I have to wait for every page to load and then wait about 3 seconds to get an Access Denied js error. Click No I don't want to debug, and then about 3 seconds after that I get another error. It makes loading each page quite cumbersome.

David Betz
February 08, 2008

# re: JavaScript Errors in the Mainstream

I see errors all the time on major web sites. People have no respect for anything these days.

Also... here this one. I'm somewhat known for my Firefox advocacy and I've done a popular video series on web development in Firefox... BUT... I must say that VS2008's attachment to iexplore.exe is phenomenal. Furthermore, while the web developer toolbar that MS ships is absolutely worthless, Nikhil Kothari's web developer helper is a very nice utility to help out with those moments when debugging IE makes you want to change careers.

I think a deeper problem is that most people have no understanding of JavaScript before they start hammering away at it. The idea of LEARNING something before DOING something is obsolete I suppose. If you have the title "web developer" or "software engineer", surely you know everything... right? Of course I see the same thing in .NET code as well. When you don't follow the framework design guidelines, you WILL get burned. Arrogant use of "subjectivity" and placing your opinions against it isn't something that's appropriate in a professional world. This is EXACTLY what I see in JavaScript constantly. People just do NOT get the idea of checking for undefined objects, they don't get the process of a page load, and also don't even remotely get the idea behind JavaScript scope. I actually hear people tell me "JavaScript scoping is stupid". How exactly does that statement change the fact that you still have to follow its rules??

The tools could use some help for sure, but I blame the people.

Christopher Bennage
February 08, 2008

# re: JavaScript Errors in the Mainstream

I bet the load errors are a result of designers testing locally, or at least _too close_ the server.

February 08, 2008

# re: JavaScript Errors in the Mainstream

I run IE with a tool called <a href='http://www.my-debugbar.com/wiki/CompanionJS/HomePage'>Companion.JS</a> loaded. It gives you excellent debugging capability, logs all errors with stack traces and lets the page keep on going without any modal interruption. Puts IEs JS error handing on par or better that FireFox's, IMO.

- Forrest

February 08, 2008

# re: JavaScript Errors in the Mainstream


Sounds like you're running an ad blocking host file, or some other filter. If you attempt to access those URLs directly, what do you get?

I've seen it quite a bit where users install a hosts file to remove ads, then wonder why they're getting tons of IE error dialogs..

Jeff West
February 08, 2008

# re: JavaScript Errors in the Mainstream

I find that a lof of scripting errors , in IE, are caused by IE addins. A large number of 3rd party addins muck with th DOM. Especially ad/image blockers. When I run into a page with errors that break the functionallity I need, I try running IE in "No Add-ons" mode and reloading the page. Most of the time the errors are unreproducable. Please note that I said "most" of the time not all of the time.


Tom Groeger
February 08, 2008

# re: JavaScript Errors in the Mainstream

I can't understand how developers can be so ignorant and not test their JavaScript and fix the errors - very unprofessional. Since years I travel the web with Script-debugging disabled - too much errors popping up, even on professional websites.

Beside a good built-in IE7 Script Debugger I would wish myself two tools: one would be a global JavaScript Error handler, that collects Script errors and sends them via AJAX to the server, from where the error can be logged or send by Email - just like the most Custom Error handlers for server-side code do.
Second would be a Website like validator.w3.org or other Markup/CSS validation services, just for JavaScript. It should test a given URL with he mainstream browsers in a sandbox and
returns a list of Errors, possibly with suggestions how to fix it. At least that would show up all load-errors ...


Rick Strahl
February 08, 2008

# re: JavaScript Errors in the Mainstream

@Michael - Not quite sure what the problem you're seeing is but I don't see this with IE debugging on. I suspect - as Nicholas pointed out - you have some sort of ad blocking software that's stripping the ads incompletely leaving invalid HTML and potentially script in its place. If you're seeing what you describe (ie. an empty HTML document) then your ad stripper really sucks because it's essentially returning what should be JavaScript content as HTML content which will ALWAY break. If anything the content should be empty for script code.

Rick Strahl
February 08, 2008

# re: JavaScript Errors in the Mainstream

@David - no doubt it's the people, but better tools would definitely help make people better <g>...

As one who's been thrown into JavaScript coding kicking and screaming myself I can relate to the difficulties in dealing with JavaScript. While I feel pretty confident with JS now, it took a while for the mindshift to kick in coming from 'conventional' languages. It doesn't help that JavaScript's been around forever but I like many others never really looked at it seriously until the AJAX rush started. Any way I look at it though JS (or DOM programming maybe) even with help of tools like jQuery feels very shaky at best.

However, testing - even if it's just top level UI testing - should be vital. It's really hard to see why so many sites are failing downright, especially bigger sites where it seems there surely must be somebody doing the final UI checking...

David Fauber
February 10, 2008

# re: JavaScript Errors in the Mainstream

"regardless of the fact that Microsoft still holds well over 80% of the browser share."

Where are you getting that number from? The numbers I see reported vary pretty wildly depending on the source, but most have it around 55%.

February 10, 2008

# re: JavaScript Errors in the Mainstream

Hi Rick,
Good post. I wonder too why so many websites produces javascript-errors nowadays. I surf with IE7 with IE7Pro installed. And I do have AD Blocker enabled. Funny, I don't see any javascript errors on this site with AD Blocker enabled/disabled. I too have to run IE7 with debugging features off because of those annoying popups. My 2 cents (in euros ;)).

Bertrand Le Roy
February 11, 2008

# re: JavaScript Errors in the Mainstream

Oh yes, I'm with you on that one. It drives me absolutely nuts. Seems like Ajax actually made the problem a lot worse. Now sites without errors are the exception. I'm not even talking about warnings.
What I've found is that most of the times it's the ads that contain the most errors.

Peter Bromberg
February 14, 2008

# re: JavaScript Errors in the Mainstream

FWIW, I get no javascript errors when loading this ShowPost .. page with IE 7 and "Disable Script Debugging..." items unchecked. I also use Debugbar.

Shaun Kester
February 14, 2008

# re: JavaScript Errors in the Mainstream

I'm regularly testing now in FF2, FF3, IE6, and IE7. My latest project works in all of them, but every so often IE7 will throw an object not found, or IE6 will not remove a modal window (remember my demo in Mesa?), or FF2 will lock up. Even with Firebug etc, JS just does that sometimes. Aggravating, but a necessary evil to meet some specs.

@Rick: I'm really looking forward to playing with the new in place editing component you built with jQuery a couple weeks ago. Very neat!

April 28, 2008

# clonedvdmovie

Register SIP phone (DPH- 140S) to Asterisk Make Skype call from internet to SIP phone Make SIP phone call to Skype Register DVG- 6004S to Asterisk Make outgoing calls to PSTN via DVG- 6004S Receive incoming calls from PSTN via DVG- 6004S Make Skype call from internet to PSTN line via DVG- 6004S Connecting DVG- 6004S The router to internet is properly setup and have access to the internet. The router shall also provide DHCP service. The PC with Asterisk and ssgwpe is properly setup and connected to the router. ...

record dvd
June 20, 2008

# record dvd

alphabetically. However some of the topics are general such as“ Shutdown problems” while others are very specific such as“ sh31w32. dll.” Once you select a topic you’ ll be shown a variety of resources ranging from Microsoft Knowledge base links to simple fix- it guides. Overall, an excellent trouble- shooting resource.

dvd shrink
June 20, 2008

# dvd shrink

Recent Posts \"Crawling\" Toward SDL SDL and Web 2. 0 The First Step on the Road to More Secure Software is admitting you have a Problem Wrapping up Threat Modeling More trustworthy election systems via SDL?

free dvd burning
June 20, 2008

# free dvd burning

how to copy dvd
June 21, 2008

# how to copy dvd

Link: Optimize Ubuntu Feisty Fawn for Speed- Tips for a faster Ubuntu machine! -

dvd decoders
June 21, 2008

# dvd decoders

Additionally, even in scenarios wher Cable/ DSL is provided by your Internet Service Provider, there can be connection/ configuration issues that slow down your network connection to a crawl. Please run one of the Bandwidth Speed Tests to see how fast your connection is operating at the moment. Rates at or above 1Mbit are acceptable for Cable/ DSL. If you are testing at or above 1Mbit and still having extreme slowness, contact VCL Support.

use dvd decrypter
June 21, 2008

# use dvd decrypter

I go to Cabell library almost everyday because it\'s a great place to study and do computer work since I don\'t have a laptop. Cabell Library has days where there are no computers in use, so I use the basement (B- 8 computer lab). I have been going for one month and in that time period NO ONE has made an attempt to keep it clean. The computer lab is VERY DISGUSTING. There are used tissues, spilled drinks, balled up papers, hair, boogers, and I mean the WORKS. Whatever you can think of you\'ll probably find it...

dvd decrypt download
June 21, 2008

# dvd decrypt download

A Trojan is a malicious and destructive code that is embedded in what appears to be legitimate or harmless software, but then it hijacks your computer and quickly spreads to do it’ s damage, such as ruining the files on your hard disk. A common and most treacherous type of Trojan is a program that claims to remove viruses and spyware from your computer but instead installs the spyware onto your computer. A Trojan is similar to a Backdoor and may be widely redistributed as part of a computer virus.

# www.FreeRegistryCleanerScan.com

There are a few places where the pen input was implemented well. The main menu, and sub menu have big icons, easy to find and use. The text input screen is another. However, the places where the pen input is poorly implemented greatly outnumber the positive uses. For example, although the menus are layered (hitting ESC will generally return you to the previous menu), there is no way to close or cancel a menu using the pen. This forces the user to use the ESC button. Another example is the create waypoint screen. ...

dvd ripper confronto
June 26, 2008

# dvd ripper confronto

my sis haven came bak frm her bowling and i\'m bored to death in a borin hse. my mum\'s givin her tuition so i guess i can\'t disturb her... and she\'s sort of preparing dinner... Bored...

bestes dvd copy software
June 28, 2008

# bestes dvd copy software

An hour after getting the box running, it died- BIG time. By this I mean it simply stopped working. Upon rebooting, the system wont even display BIOS information. My guess is that this is a hardware fault and that the CPU has died seeing as no information is displayed when the power is turned on and nothing else happens.

December 16, 2008

# re: JavaScript Errors in the Mainstream

I have a JavaScript Error dialog box showing up on the server and I'm not sure how to get rid of it. I generate the JavaScript in .Net on the Server, so I think that's why it shows up there. I am looking for a server-wide 'disable JavaScript debugging' setting because its not within a browser.
Right on the desktop the dialog says something like 'JavaScript error, do you want to continue?'
The users are unable to print Forms until I remote into the Server and click OK.

I may have to put all my JS statements in try/catch statements when .Net is generating it, but I was hoping for a quicker solution. Any ideas, Rick? Thanks for the great Blog. Say aloha to Hawaii for me.

West Wind  © Rick Strahl, West Wind Technologies, 2005 - 2024