Last Comment Bug 690031 - '__proto__' appears in Object.getOwnPropertyNames(Object.prototype) on FF7 while it didn't in FF6
: '__proto__' appears in Object.getOwnPropertyNames(Object.prototype) on FF7 wh...
Status: RESOLVED FIXED
[equity-Chrome][equity-Opera]
: regression
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: 7 Branch
: All All
: -- normal (vote)
: mozilla10
Assigned To: Jeff Walden [:Waldo] (remove +bmo to email)
:
Mentors:
Depends on:
Blocks: 636989
  Show dependency treegraph
 
Reported: 2011-09-28 11:39 PDT by David Bruant
Modified: 2011-10-07 04:06 PDT (History)
7 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Patch (2.92 KB, patch)
2011-09-29 14:13 PDT, Jeff Walden [:Waldo] (remove +bmo to email)
jorendorff: review+
Details | Diff | Splinter Review

Description David Bruant 2011-09-28 11:39:34 PDT
'__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.
Comment 1 Brendan Eich [:brendan] 2011-09-29 12:00:03 PDT
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
Comment 2 David Bruant 2011-09-29 12:08:16 PDT
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.
Comment 3 Jeff Walden [:Waldo] (remove +bmo to email) 2011-09-29 12:21:41 PDT
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.
Comment 4 Brendan Eich [:brendan] 2011-09-29 12:34:35 PDT
(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
Comment 5 Jeff Walden [:Waldo] (remove +bmo to email) 2011-09-29 14:13:40 PDT
Created attachment 563551 [details] [diff] [review]
Patch

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.
Comment 6 Jason Orendorff [:jorendorff] 2011-10-06 13:42:39 PDT
Comment on attachment 563551 [details] [diff] [review]
Patch

OK, r=me.
Comment 7 Jeff Walden [:Waldo] (remove +bmo to email) 2011-10-06 14:52:26 PDT
https://hg.mozilla.org/integration/mozilla-inbound/rev/62c09b44976f

I'll try to whip up some branch patches shortly.
Comment 8 Ed Morley [:emorley] 2011-10-07 04:06:06 PDT
https://hg.mozilla.org/mozilla-central/rev/62c09b44976f

Note You need to log in before you can comment on or make changes to this bug.