Bug 33595
| Summary: | __proto__ property of plugin object returns null | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Kent Hansen <kent.hansen> |
| Component: | WebCore JavaScript | Assignee: | Kent Hansen <kent.hansen> |
| Status: | NEW | ||
| Severity: | Normal | ||
| Priority: | P2 | ||
| Version: | 528+ (Nightly build) | ||
| Hardware: | PC | ||
| OS: | OS X 10.5 | ||
Kent Hansen
Example: In LayoutTests/plugins/netscape-enumerate.html, "plugin.testObject.__proto__" gives null as the result. "plugin.testObject.hasOwnProperty('__proto__')" returns false. Shouldn't all objects by definition have a __proto__ property, since it mirrors the internal [[Prototype]] property? In FireFox, a non-null prototype is returned, and the hasOwnProperty() call returns true.
"plugin.testObject instanceof Object" returns true, so the internal prototype actually appears to be Object.prototype.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Kent Hansen
What's happening is that RuntimeObjectImp::getOwnPropertySlot() does not call the base implementation in JSObject when the property can't be found in the instance. Hence, the prototype chain will be followed, and so the __proto__ property of the prototype (Object.prototype) is returned, whose value is null.
Should getOwnPropertySlot() call the base implementation if the property is not found in the instance? Same issue with RuntimeObjectImp::put(); currently, writes to non-plugin-defined properties (such as __proto__) will be swallowed, since the default implementation of Instance::put() does nothing. Reimplementations of Instance::setValueOfUndefinedField() already have a chance to handle writes to non-existent properties, so could any badness possibly result from calling JSObject::put() if setValueOfUndefinedField() doesn't handle the write?
A less intrusive fix would be to special-case __proto__ access in RuntimeObjectImp, but then the cycle check from JSObject::put() must also be performed.