Site Navigation

Wednesday, March 26, 2008

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

Saturday, March 22, 2008

bug 199 - can't clone a form element in IE using .cloneNode

Issue: #199
Affects: IE6, IE7, IE8

Well, yes you can clone a form element in IE using .cloneNode() but it won't work the way you need it to work.

It seems that the readonly bugs (bug 235, bug 237) for form elements affects more than just the .createElement() and .setAttribute() methods.

When you clone a node (e.g. a Form Input Element), it will obviously have a name. However that cloned element will have the same name, and it too will be readonly.

Example:

<script type="text/javascript">
function cloneEmail(quantity){
var emailAddr = document.getElementById('emailAddressTemplate');
//clone it!
var newInput = null;
var myForm = document.getElementsByTagName('form')[0];
for(var i=0;i<quantity;i++){
newInput = emailAddr.cloneNode(false);
newInput.setAttribute('name', 'emailAddr' + (i + 1));
myForm.appendChild(newInput);
}
}
</script>


Attempting to change the name in this manner will fail in IE. Calling the following will change the name for the HTTP Get/Post param name, but it won't be accessible to JavaScript by name.


newInput.name = 'emailAddr' + (i + 1);



Known Workarounds: None.



Related Issues: (bug 235, bug 237).

Bug/Site Feedback |
Submit a bug

bug 279 - onload event for images might not happen

Issue: #279
Affects: IE6, IE7, Opera (ver?)

When you add an image to a page dynamically (via the DOM) and you set the .src attribute, if IE/Opera has it in the cache it is loaded instantly, thus if you set an event handler to catch the onload after setting the source, you're onload event may never fire.

Example:

<script type="text/javascript">
var myImg = document.getElementsByTagName('img')[0];
myImg.src = 'highlight.png';
myImg.onload = function(){
alert('image loaded!');
}
</script>



Known Workarounds: One. Move the event handler up to a position before the .src is declared.

Example Workaround Code:

<script type="text/javascript">
var myImg = document.getElementsByTagName('img')[0];
myImg.onload = function(){
alert('image loaded!');
}
//define src "after" the onload handler
myImg.src = 'highlight.png';
</script>



Related Issues: None.

Bug/Site Feedback |
Submit a bug

Wednesday, March 19, 2008

bug 366 - we call a rose by any other name would... IE JS Error?

Issue: #366
Affects: IE6, IE7

"What's in a name? That which we call a rose by any other name would smell as sweet."
- William Shakespear (Romeo and Juliet, Act II, Sc. II)


Have you ever tried to rename an input field with JavaScript just before submitting a form? Quite likely, and it works just fine... or does it?

There are times when renaming a field is easier than deleting and inserting a new one. When such a time arises, a simple:

Example:

<script type="text/javascript">
document.forms[0].elements['rose'].name = 'flower';
</script>


Will work just fine. When you submit the page, the parameter on the GET/POST request/submission will be called "flower".

However if you plan to use JavaScript to re-access that field in IE (e.g. to perform some client side field validation), don't try to access it by name! It will work in all browsers except Internet Explorer.


Known Workarounds: None.



Related Issues: (bug 152), (bug 162), (bug 235), (bug 237), (bug 240), (bug 242), (bug 411).

Bug/Site Feedback |
Submit a bug

Tuesday, March 18, 2008

bug 126 - no W3C DOM Level 2 Event Listeners

Issue: #126
Affects: IE6, IE7, IE8
Partially Fixed in: IE9 RC 1 (events are still not possible on option/optgroup elements (bug 280))
Status: Microsoft has confirmed this will NOT be fixed in IE8 RTM


MSIE Feedback ID: 333958



The W3C published the specs for (W3C DOM2 Event Listeners) on or before November 13th, 2000. This means that the spec has been available for over seven years. When it wasn't present in IE6, the development community couldn't complain. When it was omitted from IE7 (they were still too busy trying to catch up) it was unfortunate, but accepted. However we are now at the dawn of IE8 (currently in Beta) and there is still no sign of DOM2 Event Listeners. Therefore this is no longer just a "we haven't had the time yet" or "we have higher priorities" issue, this is now a genuine bug!

Example:

<script type="text/javascript">
var obj = document.getElementById('foo');
obj.addEventListener('click', myClickHandler, false );
</script>



Known Workarounds: One. Create your own "addEvent" function that attempts to best handle IE's missing implementation by wrapping "attachEvent" in a cross-browser implementation.

Example Workaround Code:

//soon



Related Issues: (bug 186).

Bug/Site Feedback |
Submit a bug

Sunday, March 16, 2008

bug 347 - IE8 Beta 1 - text highlighting background issue

Issue: #347
Affects: IE8 Beta 1
Fixed: IE8 Beta 2

In IE8 Standards Mode, if you have a block element (e.g. a div) with a background image applied, when the user selects text within the block, the background image is re-applied to the selection with a new offset matching the top left of the selection.


Known Workarounds: None.



Related Issues: None.

Bug/Site Feedback |
Submit a bug

bug 329 - Element.setAttribute('style', '...') fails in IE8 Beta 1

Issue: #329
Affects: IE8 Beta 1
Also Affects: IE6, IE7
Fixed In: IE8 RC1

The setAttribute() method was reported fixed in IE8 (whitepaper Pg.5), however some tests have indicated otherwise.

In particular, attempting to set the 'style' attribute on an element in IE8 Beta 1 still fails as it did in IE6, & IE7.

Please note that for any IE8 related bugs, all tests are done in "IE8 Standards Mode".

Example:

<script type="text/javascript">
var obj = document.getElementById('myObj');
//the following call will fail in IE8 Beta 1
obj.setAttribute('style','border:2px solid #ff0000;color:#00ff00;');
</script>



Known Workarounds: One. Although you can set: obj.style.setAttribute('cssText','...'); as outlined in (bug 245) IE8 was supposed to fix this, thus this is not an ideal workaround.



Related Issues: (bug 245), (bug 242).

Bug/Site Feedback |
Submit a bug

Sunday, March 2, 2008

bug 240 - setAttribute "name" is half broken in IE

Issue: #240
Affects: IE6, IE7

Setting the name attribute of an element in IE is complicated at best (bug 242). Using .setAttribute('name', 'someValue'); will fail in IE. The name attribute is ~readonly~ and can't be modified. However interestingly enough, if you do set this, if the name was applied to a form field, IE will send the correct parameter name on the POST/GET request.

It is highly recommended that you apply some version of the (bug 235) workaround to avoid this bug in IE.


Known Workarounds: One. Use the hack in bug 235.



Related Issues: (bug 242), (bug 235)

Bug/Site Feedback |
Submit a bug

bug 165 - dynamic pre population fails in IE

Issue: #165
Affects: IE6, IE7, IE8
Fixed in: IE9 PP4

The <pre> tag is the one tag that will allow you to put pre-formatted content on the screen. It's the only way to display code or structured text without losing all the whitespace markup.

What's odd, is that you can't set the contents in IE using .innerHTML because if you do, you will lose all of your whitespace formatting.

Example:

<script type="text/javascript">
myPreObj.innerHTML = 'This\nWill\nFail... no linebreaks or spaces';
</script>



Known Workarounds: One. Setting the .innerHTML to well the .innerHTML magically fixes this issue (and some others in an upcoming article).

Example Workaround Code:

<script type="text/javascript">
myPreObj.innerHTML = 'This\nWill\nFail... no linebreaks or spaces';
myPreObj.innerHTML = myPreObj.innerHTML;
</script>



That's right! "Set my inner content, to my inner content" - fixes this bug in IE... go figure?

Related Issues: One. It has come to our attention that trying to append a text node to the pre element via appendChild() will fail to handle whitespace properly and the hack above to set the innerHTML to itself will not fix it.

Bug/Site Feedback |
Submit a bug