What are the typical reasons Javascript developed on Firefox fails on IE?

Question

I developed some javascript enhanced pages that run fine on recent Firefox and Safari. I missed to check in Internet Explorer, and now I find the pages don't work on IE 6 and 7 (so far). The scripts are somehow not executed, the pages show as if javascript wasn't there, although some javascript is executed. I am using own libraries with dom manipulation, from YUI 2 I use YUI-Loader and the XML-Http-Request, and on one page I use "psupload", which depends on JQuery.

I am installing Microsoft Script Editor from Office XP and will now debug. I will also write specific tests now.

What are the typical failing points of IE? What direction I can keep my eyes open.

I found this page, which shows some differences: http://www.quirksmode.org/compatibility.html

Can you from your experience name some typical things I should look for first?

I will also ask more questions here for specific tasks later, but for now I am interested in your experience why IE usually fails on scripts that run fine in Firefox

Edit: Thank you for all those great answers!

In the meantime I have adapted the whole code so that it also works with Internet Explorer. I integrated jQuery and built my own classes on top of it now. This was my basic mistake, that I did not build all my stuff on jQuery from the beginning. Now I have.

Also JSLint helped me a lot.

And many of the single issues from the different answers helped.

Answer 1

If you stick to using jQuery or YUI as your post is tagged, you should have minimal differences between browsers...that's what the frameworks are for, to take care of these cross-browser differences for you.

For an example, look at the quirksmode DOM traversal page, according to it IE doesn't support most things...while true, the frameworks do, for example IE doesn't support elem.childElementCount, but in jQuery: $(elem).children().size() works to get this value, in every browser. You'll find there's something in the library to handle 99% of the unsupported cases across browsers, at least with script...with CSS you might have to move to plugins for the library, a common example of this is to get rounded corners working in IE...since it has no CSS support for such.

If however you start doing things directly, like document.XXX(thing), then you're not in the library, you're doing javascript directly (it's all javascript, but you get the point :), and this might or might not cause issues, depending on how drunk the IE team was when implementing that particular function.

With IE you're more likely to fail on styling coming out right than raw javascript issues, animations a few pixels off and that sort of thing, much more-so in IE6 of course.

Answer 2

There are loads of things, but one trap I used to fall in was that many browsers accepts JSON without quoted names, while ie6 and ie7 does not.

{ name: "Jakob" } // will often work, but not in ie6/ie7
{ "name": "Jakob" } // Better!

Edit: To clarify, this is only an issue when actual JSON is required, as opposed to an object literal. JSON is a subset of the object literal syntax and is meant as a data exchange format (like XML) which is why it's designed to be pickier.

Answer 3

Check also for commas such as these or similar if any in your code

var o={
'name1':'value1',
'name2':'value2',
} 

the last comma (following value2) will be tolerated by Firefox, but IE

Answer 4

Trailing commas in arrays and object literals used to be a problem, haven't checked recently (meaning IE8):

var a = [ 1, 2, 3, ];
var o = { a:1, b:2, c:3, };

This would cause some extra code when generating such structures server side.

Answer 5

Some native objects are read-only without really seeming to be so (you can write to them but it has no effect). For example, a common advanced javascript is based on extending the Element object by overriding system methods, say, changing Element.prototype.appendChild() to do more than appending a child node - say, initialize it with parent's data. This will fail silently on IE6 - original method will be invoked on new objects instead of the new one.

Some browsers (I don't remember which now) consider newlines between HTML tags to be text nodes, while others don't. So childNodes(n), nextSibling(), firstChild() and the like will behave very differently.

Answer 6

Extra commas and missing commas used to be usual problem on IE while it works smoothly on FF.

Answer 7

IE is not a modern browser and only follows ECMAScript loosely.

Answer 8

IE is very strict about missing ";" so is usually that.

Answer 9

getElementbyID will also match against the name attribute in IE, but not other browsers, and IE will select whichever it finds first.

example:

<script>
 var foo = document.getElementById('bar');
</script>

....
<input name="bar" type="text" />  //IE will get this element
<span id="bar"> Hello, World! </span>  //FF,Safari,Chrome will get this element

Answer 10

I just found one this morning, a co-worker set the script tag as: <script type="application/javascript"> because his ide autocomplete had that before "text/javascript"

But, it turns out that IE just ignores the entire script if you use "application/javascript", you need to use "text/javascript"

Answer 11

You mentioned jQuery which I'm less familiar with but for general reference, and specifically with Prototype, one thing to watch out for is reserved words / method names in IE. I know what often gets me is things like:

someElement.appendChild(new Element('label',{ **for**: someInput.id }).update( someLabelText );

(new Element(tagName, propertyHash) is how new elements are created in Protitype). In IE, for: must be 'for':, because for is a reserved word. Which makes complete sense -- but FireFox will tolerate this.

Another example:

someElement.wrap('div').addClassName('someClass')

(the wrap method in Prototype wraps one element in another) -- In IE, on textareas, wrap is a property, and Element.wrap() must be used instead of the methodized version

These are two examples which come to mind from my experience. They're based on prototype but the core issue isn't: Watch out for any methods/labels/identifiers which IE considers reserved words but FireFox or Safari will tolerate.

Answer 12

The fact is that IE doesn't support JavaScript... It supports his own implementation of ECMAScript : JScript... which is kind of different...

Answer 13

Using console.log() for outputting errors to the Firefox error console will cause your scripts to fail in IE. Got to remember to take those out when you test in IE.

Answer 14

I found an odd quirk just the other day with Internet Explorer. I was using YUI, and replacing the contents of a table body () by setting the innerHTML

Y.one('#elementId').set('innerHTML', '<tr><td>Column 1</td></tr>');

This would work in all browsers EXCEPT IE. I finally discovered that you couldn't replace the innerHTML of a table in IE. I had to create a node using YUI and then append that node.

var myNode = Y.node.create('<tr><td>Column 1</td></tr>');
Y.one('#elementId').append(myNode);

That was a fun one to figure out!

Answer 15

Differing JavaScript Support

IE doesn't support (most of) the extensions added to JavaScript since 1.5.

New in 1.6

• Array Methods - indexOf(), lastIndexOf(), every(), filter(), forEach(), map(), some()
• for each ... in - iterates values instead of property names.

New in 1.7

• Destructuring assignment -- [a,b] = [1,2]
• Iterators and Generators
• let and yeild

New in 1.8

• Array Methods - reduce(), reduceRight()
• Shortcuts for defining functions.

Some of these things require you to specify a version number of JavaScript to run under (which will break under IE), but some things like [1,2,3].indexOf(2) might not seem like that big a deal, until you try to run it in IE

Answer 16

The major differences between JavaScript in IE and JavaScript in modern browsers (ex, Firefox) can be attributed to the same reasons behind the differences in CSS/(X)HTML cross-browser. Back in the day there was no de facto standard; IE/Netscape/Opera fought a turf war, implementing most of the specs, but also omitting some as well as making proprietary specs to gain advantages over each other. I could go on at length, but lets skip ahead to the release of IE8: JavaScript was avoided/scorned for years, and with the rise of FF and the contempt of webcomm, IE chose to focus mostly on advancing their CSS from IE6 on. And basically left DOM support behind. IE8's DOM support might as well be IE6's, which rolled out in 2001....so IE's DOM support is nearly a decade behind modern browsers. If you are having JavaScript discrepancies particular to a layout engine, you're best bet is to attack it the same way we took on the CSS problems; Targeting that browser. DON'T USE BROWSER SNIFFING, use feature detection to sniff out your browser/it's level of DOM support.

JScript is not IE's own implementation of ECMAScript; JScript was IE's answer to Netscape's JavaScript, both of which came into existence before ECMAScript.

As far as type attributes on the script element, type="text/javascript" is the default standard (at least in HTML5), so you don't ever need a type attribute unless your script isn't JavaScript.

As far as IE not supporting innerHTML...innerHTML was invented by IE and is still today NOT a DOM standard. Other browsers have adopted it because it's useful, which is why you can use it cross-browser. As far as dynamically changing tables, MSDN says "because of the specific structure required by tables, the innerText and innerHTML properties of the table and tr objects are read-only." I don't know how much of that was true initially, but clearly the modern browsers have figured it out while dealing with the complexities of table-layout.

I highly recommend reading PPK on JavaScript Jeremy Keith's DOM Scripting Douglas Crockford's JavaScript: The Good Parts and Christian Hellman's Beginning JavaScript with DOM Scripting and Ajax to get a strong grasp on JavaScript.

As far as Frameworks/Libraries are concerned, if you don't have a strong grasp on JavaScript yet, you should avoid them. 2 years ago I fell into the jQuery trap, and while I was able to pull off magnificent feats, I never learned a damn thing about coding JavaScript properly. In hindsight, jQuery is a wicked awesome DOM Toolkit, but my failure to learn proper closures, prototypical inheritance, etc., not only set my personal knowledge back, my work starting taking huge performance hits because I had no clue wtf I was doing.

JavaScript is the language of the browser; if you are client-side/front-end engineer it is of upmost importance that you command JavaScript. Node.js is bringing JavaScript full tilt, I see immense strides taken daily in its development; Server-side JavaScript will be a standard in the very near future. I'm mentioning this to further emphasize just how important JavaScript is now and will be.

JavaScript is going to make more waves than Rails.

Happy Scripting!