What are the most likely causes of Javascript errors in IE8?

Question

I'm seeing a lot of Javascript errors in IE8 on pages which worked fine in IE7 (and Firefox, Chrome, and Safari). I know that IE made some changes to things like Javascript security. Some of these don't give clear error messages - things like cross-domain violations can end up throwing very vague exceptions.

Let's make a checklist of top offenders when we're troubleshooting IE8 Javascript errors. Please list one change to the way IE8 Javascript that would cause a Javascript error.

Answer 1

I can verify that the ones posted by "unique_username" are accurate!

(quote) Actually a TON of stuff has changed.

First off, it REALLY matters what mode you are in. In IE8, there are 3 (THREE) modes.

• IE5 Quirks - your page has no doctype, page renders like IE5 did
• IE 7 Standards Mode - you have a doctype, but either opted out of IE8 standards mode, or are running on localhost, or in "Compatibility Mode"
• IE 8 Standards Mode - you have a doctype, and are on the INTRANET (default mode)

Now, if you are rendering in IE5/IE7 mode, then Nothing changes except that there will be a few methods added that shouldn't interfere with your page.

However, if like the majority, you are running with a doctype set, and thus in IE8 Standards mode, the following changes have occurred.

1.) document.getElementById( id ); //now only returns the CORRECT matches!

2.) .getElementsByName( name ); //now only returns the CORRECT matches! nope, not fixed!

3.) .getAttribute( name ); //returns the CORRECT value for the given attribute!
4.) .setAttribute( name, value ); //actually SETS the name/value CORRECTLY (no more cAmElCaSe crud)!
5.) CSS Expressions are NO LONGER allowed (deprecated)
6.) Operation Aborted errors will still be thrown (in some cases) however the cases are fewer, and the error won't kill the entire page/DOM
7.) The attributes[] array on elements should (from the RC build onwards) be correct in terms of contents, have a length, etc.
8.) Button elements now submit the contents of the value attribute, NOT the HTML contents of the Button Tag

There has also been a bunch of CSS 2.1 fixes, so things that rendered weird before, or needed hacks, should be much better. (see below for details on alpha/transparency - there's been big changes)

See the IE Blog for details.

Also see Web Bug Track for fine grained details on Bugs, Fixes for IE8 (and all other browsers)

SVG, rounded corners, ECMAScript based Event Listeners, Better Form Element design/events etc. are still missing.

PS If you have specific issues, let us know and we'll help hunt them down for you. ;-)

Updates:

window.resize events are currently broken in IE8 Beta2 and IE8 Partner Release 1 (will not fire) now fixed in RTM build

window.open(); in IE8 Partner Release is sometimes failing "claiming" that the target url is not available (quirky, hard to reproduce)

Answer 2

Here's a REALLY fun one (/sarcasm off) that I discovered. If you have a MIME type of "application/javascript", rather than "text/javascript" Internet Explorer will:

A) ignore the unexpected MIME type and use the file anyway?

B) not load the file at all?

C) take the first hundred or so lines of the file, prepend them to another JS file that comes before it in the HTML, and then give you all sorts of errors because your out-of-order half file + actual file doesn't work?

That's right, the answer is C ... I kid you not. We used to use the "application/javascript" MIME type to prevent JS file caching in IE6/7, and as a result I wasted an entire day trying to figure out why IE8 was giving some really crazy errors. Luckily I finally figured out what was going on when it told me I had an error on line 650 of a 500 line file (and then when I viewed the file in the debugger I saw the prepended other file).

Moral of the story: if you want IE8 to work DO NOT use "application/javascript" for your JS files' MIME type.