[Webkit-unassigned] [Bug 33159] Make JSObject::getPropertyNames() non-virtual

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Jan 8 03:21:33 PST 2010


https://bugs.webkit.org/show_bug.cgi?id=33159





--- Comment #8 from Kent Hansen <kent.hansen at nokia.com>  2010-01-08 03:21:32 PST ---
(In reply to comment #6)
> > JSC::Bindings::Instance and friends: When enumerating such objects, the
> > properties in the prototype chain will now be included as well. I'm not sure
> > whether this is desirable or not. E.g. if you use an NPObject in a for-in
> > statement, should the properties in the prototype chain be included?
> 
> Yes, I think so. You can write a test for this behavior by adding a property to
> Object.prototype, and then checking to see that the property shows up when
> enumerating the properties of a plugin object.
> 
> > The RuntimeObjectImp::getOwnPropertyNames() implementation seemed broken; it
> > simply called itself recursively with the same arguments, causing a stack
> > overflow if you called e.g. Object.keys() on such an object.
> 
> Yes, that looks broken. 

Spun off https://bugs.webkit.org/show_bug.cgi?id=33371 for the infinite
recursion bug.
I also hoped that it would, as a nice bonus, fix the "properties in the
prototype chain should be included when enumerating an NPObject" issue, but no.
I checked in FireFox, and there the prototype properties are included in the
enumeration.
The problem in JSC/WebCore seems to be that the __proto__ property of a plugin
object can't be assigned to, and it always reads as null.
I'm investigating whether this is on purpose or if it's a bug as well.

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