I think I've found a bug in IE's (IE8) handling for the for-in javascript statement. After several hours of boiling this down to a small example, it looks like IE specifically skips any property called "toString" in a for-in loop - regardless of whether it is in a prototype or is an "Own Property" of the object.
I've placed my test code here:
function countProps(obj) {
var c = 0;
for (var prop in obj) {
c++;
}
return c;
}
var obj = {
toString: function() {
return "hello";
}
};
function test() {
var o = "";
var d = document.getElementById('output');
o += "<br/>obj.hasOwnProperty('toString') == " + obj.hasOwnProperty('toString');
o += "<br/>countProps(obj) = " + countProps(obj);
o += "<br/>obj.toString() = " + obj.toString();
d.innerHTML = o;
}
This should produce:
obj.hasOwnProperty('toString') == true
countProps(obj) = 1
obj.toString() = hello
but in IE, I'm getting:
obj.hasOwnProperty('toString') == true
countProps(obj) = 0
obj.toString() = hello
This special casing of any property called 'toString' is wrecking havoc with my code that tries to copy methods into a Function.prototype - my custom toString function is always skipped.
Does anyone know a work-around? Is this some sort of quirks-mode only behavior - or just a BUG?
Yes, it is a bug. See this answer.
Quoting CMS:
Another well known JScript bug is the "DontEnum Bug", if an object in its scope chain contains a property that is not enumerable (has the { DontEnum } attribute), if the property is shadowed on other object, it will stay as non-enumerable, for example:
var dontEnumBug = {toString:'foo'}.propertyIsEnumerable('toString');
It will evaluate to false on IE, this causes problems when using the for-in statement, because the properties will not be visited.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With