689717 - JS: ES5 setters on prototypes return "true" for Object.hasOwnProperty

Status: RESOLVED DUPLICATE of bug 637994

(Core :: JavaScript Engine, defect)

Description

[Sean Wilkinson]

Attachment: hasOwnProperty-setter-demo.js

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_1) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/14.0.835.186 Safari/535.1

Steps to reproduce:

I constructed a test script for Spidermonkey (JavaScript-C 1.8.5 2011-03-31) to experiment with a new functional pattern. The pattern is an alternative to the usual "lazy-loading" pattern; it uses prototype methods to graft missing instance methods onto objects, since the prototype methods will never be called if the instance methods already exist. I then wondered what would happen if I used ES5 getter/setters directly on a prototype object in order to achieve the same purpose ...


Actual results:

Spidermonkey's behavior deviates from every other JS implementation I can get my hands on, including the 1.8.0 version from a few years ago. It returns "true" for an "Object.hasOwnProperty" call, even though the property (a setter) is on the prototype and not on the instance itself.


Expected results:

It should have returned "false" initially, just as all other implementations do. I have also noted that this problem is present in Firefox 6.0.2. I have enclosed the test script, which targets a command-line shell, but it will run in any webpage by changing "print" to "console.log" or "alert", etc. I understand that it's not necessarily obvious *why* I want to do this, but I would prefer a response that explains what the correct behavior should be rather than a soapbox about why that pattern shouldn't be used. After looking through the ES5.1 standard, my understanding is that my program should return "false" as its first output instead of "true" ...

Comment 1

[Boris Zbarsky [:bzbarsky]]

When I run that testcase in a current JS shell, it prints "false" then "true".

Same thing in Firefox 7 with alert.

I do see the problem in Firefox 6.

So presumably this got fixed sometime back in May....

Comment 2

[Jeff Walden [:Waldo]]

Yeah, this got fixed a bit ago, bug 637994.