'__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.
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.
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.
(In reply to Jeff Walden (remove +bmo to email) from comment #3)
> Bug 636989 removed the explicit omission of __proto__ from prototype-less
You mean from Enumerate? Easy to put back. Want to patch? r=me in advance.
Created attachment 563551 [details] [diff] [review]
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 on attachment 563551 [details] [diff] [review]
I'll try to whip up some branch patches shortly.