Closed Bug 690031 Opened 8 years ago Closed 8 years ago
__' appears in Object .get Own Property Names(Object .prototype) on FF7 while it didn't in FF6
'__proto__' appears as an own property of Object.prototype while it shouldn't. It didn't in FF6, it does in FF7. It doesn't appear as a property of Object.prototype neither in Opera 12 nor latest Chrome. __proto__ has no spec, but in my opinion should not be exposed as a property.
We originated __proto__ and it has always appeared as a property of Object.prototype. Until recently, through a nasty hack no longer in SpiderMonkey (JSPROP_SHARED meaning appears as "own"; it still means "no value slot"), __proto__ would appear to be "own" in every object that delegates to some Object.prototype. Please don't rewrite history. __proto__ may get an Annex B (normative optional) spec in ECMA-262 but it's not anywhere near for sure that we'd spec what V8 does. The Rhino-like hardcoding in [[Get]] and [[Put]] breaks JSON, among other things, and creates the effect of a property for those internal methods without the appearance of one via "in", hasOwnProperty, etc. That seems worse, especially the "breaks JSON" bit. /be
Sorry, I was not accurate enough. The difference between FF6 and FF7 I have noticed is that '__proto__' appears in Object.getOwnPropertyNames(Object.prototype) on FF7 while it didn't on FF6.
Summary: '__proto__' appears as an own property of Object.prototype → '__proto__' appears in Object.getOwnPropertyNames(Object.prototype) on FF7 while it didn't in FF6
Bug 636989 removed the explicit omission of __proto__ from prototype-less objects. I wish I'd noticed that at the time, as it doesn't seem like something we should have done. :-\ Introspection of Object.prototype seems uncommon, but not particularly so, enough to warrant leaving the hack in place.
OS: Linux → All
Hardware: x86 → All
(In reply to Jeff Walden (remove +bmo to email) from comment #3) > Bug 636989 removed the explicit omission of __proto__ from prototype-less > objects. You mean from Enumerate? Easy to put back. Want to patch? r=me in advance. /be
Yeah, that's what I meant. Enumerate got reorganized somewhat in that change, so I'm not entirely comfortable pocketing the r=me for it, because exactly where you put the check matters, and doesn't (without more adjustment) preserve the exact previous semantics. I could preserve the exact exact semantics if really desired. Maybe that's worth doing for backports to branches. We can discuss after looking at this, which is only trunk-targeted for the moment.
Assignee: general → jwalden+bmo
Status: NEW → ASSIGNED
Attachment #563551 - Flags: review?(jorendorff)
Comment on attachment 563551 [details] [diff] [review] Patch OK, r=me.
Attachment #563551 - Flags: review?(jorendorff) → review+
https://hg.mozilla.org/integration/mozilla-inbound/rev/62c09b44976f I'll try to whip up some branch patches shortly.
Target Milestone: --- → mozilla10
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.