House of Metnetsky

I came across a fun little issue today that I think should have been more obvious to me. Apparently, and I can’t believe I’m saying this: IE and Firefox parse Javascript differently. Take the following code:

var foo = [
{'one': 1},
{'two': 2},
];

What should the length be? In Firefox 2 & 3 the length is 2, but in IE7/IE8 the length is 3. I can’t confirm this, but considering I figured this out due to a *NEW* bug in one of our products, I think this is somewhat new in IE.

On a side note, it’s interesting that IE even parses the above considering the following code will break:

var foo = {
'one': 1,
'two': 2,
}

The difference here is of course that foo in the second example is an object, whereas the first example it’s an array.

A long time ago when I first started doing a lot of REST + Ajax developement I hit a really strange issue. Apparently, if your server returns a HTTP Status code of 204 in response to a POST method IE partially blows up. Part of this has to do with IE requiring try/catch blocks around code that could be devastating – like XMLHttpRequest.send()? And part of it has to do with IE not parsing a 204 response.

Upon receipt of 204 IE appears to halt parsing as the XMLHttpRequest instance becomes corrupt and is no longer usable. Checking true/false against the instance works (and is false), but querying a method or variable from the instance produces an error.

var xhr = null;

try {
    // without try/catch IE throws error for no good reason
    xhr = new Ajax.Request(url, options);
} catch (exe) {
    /* will never fail on IE for 204 */
    console.error(exe);
}

// xhr is invalid for IE + POST + 204
if (xhr) {
    resp = xhr.transport;
} else if (/^post$/i.test(method) && this.isInternetExplorer()) {
    resp = this.FAKE_204_RESPONSE();
}

I vaguely remember reading on some site that IE fails on POST + 204 because it helps the browser short circuit and keep from redrawing the interface from a <form/> submission. This sort of makes sense because you can then upload/POST form data without having to redraw the page and still know if everything succeeded.

Either way, it is truly annoying. And the only reason I’m evening posting about this, other than education and helping myself remember, is that my original comments around the code above was vulgar. It happened to have been 3AM or so and my polite-o-meter wasn’t working well. It is now almost three years later and I believe some people have seen the original comments and didn’t find it appropriate – to which they are correct.

With that said – Internet Explorer has some weird quirks.

Why is it that IE7 and IE8 Beta 2 still can’t quit get the <object/> tag correct? When using Javascript to “dynamically” add object tags to the interface my experience, bad luck, and bouts of pain teach me that using the DOM API just doesn’t cut it. Well, to be fair the following functions don’t cut it:

• document.createElement
• document.createAttribute
• [DOMElement].setAttribute(key, value)
• [DOMElement].setAttributeNode([DOMAttribute])

For any and all other “dynamic” HTML modifications the above functions work great! But if I use them to embed Flash or Silverlight movies it just tanks. Instead you have to construct ugly strings that represent the HTML you want and use [DOMElement].innerHTML. When you do this, suddenly the .swf/.xap loads and all is well.

Why oh why?

And for anyone who cares, following file does a decent job of HTML generation within Javascript… except for IE and the <object/> tag…. and input of type radio (WTF!).

http://cowarthill.com/blog/wp-content/uploads/2008/11/html_obj.js

I’ve been a long time hater of Flash as a web-service consumer because of its inability to use any HTTP method other than GET or POST. People revert to stupid URL argument tricks like ?_method=DELETE and actually use a GET or POST, neither of which work if your service layer is actually … truly … RESTful.

Silverlight has the same damn issue. Apparently none of the blog posts I read a WHILE back (2+ yrs) mentioned the fact that Flash, and now Silverlight, use the lowest common denominator for their web request classes…. NPAPI (Gecko/Mozilla Plugin SDK). I’m sure there are good reasons for using the embedded ones, security, re-usability, performance too – but it’s rather annoying!

Why the NPAPI developers don’t augment the API, I have no idea. But at least Silverlight allows for a HTML event to trigger the OpenFileDialog.ShowDialog() without having to do fun invisible overlays.

Silverlight:
http://wilcob.com/Wilco/Silverlight/http-requests-in-silverlight.aspx

Flash:

http://livedocs.adobe.com/flex/3/langref/flash/net/FileReference.html
http://theflashblog.com/?p=423