[Webkit-unassigned] [Bug 33053] JSON.stringify and JSON.parse implementations needlessly process properties in the prototype chain

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon Jan 4 02:33:57 PST 2010


--- Comment #8 from Kent Hansen <kent.hansen at nokia.com>  2010-01-04 02:33:56 PST ---
(In reply to comment #6)
> JSC produces "{"foo":"PASS"}" even with json2.js. That code uses for..in in
> combination with hasOwnProperty() to only process "own" properties of the
> object.

Looks like a bug in the for..in implementation.

js> a={__proto__:{foo:"bar"}, get b() { this.foo="PASS"; }};
({get b () {this.foo = "PASS";}})
js> for (var p in a) print(p, a[p], a.hasOwnProperty(p))
b undefined true

> a={__proto__:{foo:"bar"}, get b() { this.foo="PASS"; }}
[object Object]
> for (var p in a) print(p, a[p], a.hasOwnProperty(p))
b undefined true
foo PASS true

ES5 section 12.6.4 states that "if new properties are added to the object being
enumerated during enumeration, the newly added properties are guaranteed not to
be visited in the active enumeration." So, the "foo" added by the b getter
should not be included in the enumeration.
The reason the "foo" in the prototype should not be included is because of the
"no-shadowing" rule, also given in section 12.6.4. I.e. it looks like even
though newly added properties are not included in the enumeration, they do
affect shadowing (at least if you take SpiderMonkey's implementation to be

Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

More information about the webkit-unassigned mailing list