bug 284 - no native XMLHttpRequest object in IE

Issue: #284
Affects: IE6, IE7, IE8

What!? you say? "They added this in IE7!" - Well yes, no, not quite!

Microsoft did add a non-ActiveX version of XMLHttpRequest ("XHR") so that if a user had turned off ActiveX for security reasons, AJAX would still work (this was a good thing).

However there is a key feature of JavaScript Objects that makes them so useful is that you can Prototype on them to add properties, methods, expando properties, or even subclasses. In addition it doesn't extend from Object, thus any prototyping done there won't be available on XHR, and none of the methods on XHR are exposed.

In IE6, the XHR Object was an ActiveX control only, in IE7 they added a "native" one, but it was just access to the XHR Object that didn't require ActiveX. In IE8 Beta 1 there are no changes, but In IE8 RTM, will we see a true native XMLHTTPRequest Object?


Example:

Lets say you wanted to improve the user experience when an AJAX request is sent to the server.

• You might want to set a timeout that a response is expected by, and if it isn't cleared, automatically call an error handler.


• You might want to queue up/discard duplicate requests if the browser has already sent a request in, and is waiting for a response.


• You might want to add some debug capabilities to trace the progress of your AJAX Requests


• Since an AJAX request might be very expensive on your server, you might want to add the ability to pass in a "cancellation" request, that is "tied" to the original request... this way if the user closes a window, or runs another query, you could send a quick "one-way" request to the server to cancel the first request.

In any of these cases, being able to store applicable info on the XHR object is ideal, and adding methods would enable callbacks to be self-contained.

<script type="text/javascript">
  var myXHR = new XMLHttpRequest();
  myXHR.lastAccess = null;
  myXHR.requestTimeout = 15000;
  myXHR.requestTimeoutHandler = myTimoutHandler;
</script>

The above will fail in IE, since expando's and prototypes are not an option.

Want to see what Properties/Methods are exposed on XMLHttpRequest in your browser?
Click the button to find out! (check in other browsers too)


(PS If you subscribe to this Blog via RSS/Atom, please try the button on the Blog site as we needed to update the sample several times to overcome some Blogger auto-line-break issues. - thanks)

Known Workarounds: None.

Related Issues: (bug 186), (bug 181).

Bug/Site Feedback |
Submit a bug

bug 181 - can't subclass an Array in IE

Issue: #181
Affects: IE6, IE7, IE8 Beta 1
Fixed In: IE8

MSIE Feedback ID: 334333 (related to the attributes Array)

The #1 rule in OOP (Object Oriented Programing) is that you don't prototype on native objects. This is why many developers do not like the Prototype.js and similar JS Libraries, and where designing for expected behavior of objects is key.

Lets say you want to subclass the Array object, so that you can enjoy using an .each() method on an Array, in browsers before Firefox 3 etc.

No problem, just add this:

Example:

<script type="text/javascript">
  var MyArray = function(){
    //define your "class"
  };
  MyArray.prototype = new Array;
  //now add your method...
  MyArray.prototype.each = function(ref){
    //do your magic...
  }
</script>

This will work perfectly fine in all browsers, except IE. IE will not update the MyArray instances properly to return the correct length when requested. This of course is rather catastrophic, as it is the only way to know how "big" the array is when iterating over it!

Curious as to why it doesn't work? Well the folks at Microsoft's JScript team let the cat out of the bag and it turns out, that internally it isn't an Array, but rather a HashTable, thus explaining why the performance (pre IE8) was horribly slow, and sub classing just wasn't an option.

Known Workarounds: None. Well, this isn't entirely true. If you "steal" an array from another frame, you can cater it to your needs, but it gets quite involved and it still isn't a true sublass (e.g. you can't re-subclass it) See Dean Edwards Blog post here for more info.

Related Issues: None.

Bug/Site Feedback |
Submit a bug

bug 186 - Can't prototype on HTMLElements in IE

Issue: #186
Affects: IE5, IE5.5, IE6, IE7, IE8 Beta 1

MSIE Feedback ID: 333956

Description: The ability to prototype on any HTMLElement (doesn't matter which kind, e.g. HTMLFormInputElement, HTMLFormButton, etc. (see all element types)) is not possible in Internet Explorer. This frustrates many developers because being able to do so would allow them to workaround almost any other bug in IE.

Example: calling HTMLFormElement.prototype.preSubmit = function(){...} will not work, although it works in all other Modern Browsers.

Known Workarounds: None.

Related Issues: Any issue with missing or broken implementations for other elements in Internet Explorer.

Microsoft Internet Explorer

Microsoft Internet Explorer (IE):

Developing for the IE browser is quite challenging, due to all the bugs. For example, if your form doesn't get submitted, by clicking on an input element of type="submit", IE won't save the users info for future use with the AutoComplete feature (bug 137). This would be easily solved, if you could use JavaScript to prototype on the HTMLFormElement, but that too (bug 186) is not possible. Other bugs like (bug 153) cause frustration because the code appears to be completely fine, but renders errors/blank pages in IE. Best of all, when developers start using the Browser-Independent DOM Methods, they still lose out! IE doesn't support the .setAttribute() method properly (bug 242) and the .getElementById() method returns incorrect data! (bug 152).

Some bugs are just so strange, like the Magic Mystery HTTP Requests (bug 223), and then there are the bugs discovered when a workaround is discovered for another bug (but we'll let you see if you can find those ones!)