690031 - '__proto__' appears in Object.getOwnPropertyNames(Object.prototype) on FF7 while it didn't in FF6

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[David Bruant]

'__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]]

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]

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]]

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]]

(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]]

Attachment: 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]]

Comment on attachment 563551 [details] [diff] [review]
Patch

OK, r=me.

Comment 7

[Jeff Walden [:Waldo]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/62c09b44976f

I'll try to whip up some branch patches shortly.

Comment 8

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/62c09b44976f