Incorrect behavior for expandos shadowing prototype properties for list bindings

RESOLVED FIXED

Status

()

Core
DOM
RESOLVED FIXED
6 years ago
5 years ago

People

(Reporter: bz, Assigned: peterv)

Tracking

unspecified
x86
Mac OS X
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

Created attachment 628197 [details]
Testcase

See attached testcase.  It should say "PASS".

The key part is that ListBase<LC>::getOwnPropertyDescriptor returns a desc with a null obj during the expando set.  So we never define the new property on the object itself and don't reach the (correct-looking) ListBase<LC>::defineProperty.

The obligatory spec bits....

* We enter in ECMA-262 ed 5 section 11.13.1 (Simple Assignment ( = )).
  Step 5 calls PutValue.
* In PutValue (section 8.7.2), step 4 calls the [[Put]] internal method of the
  object.
* In [[Put]] (section 8.12.5) step 1 calls [[CanPut]]
* In [[CanPut]] (section 8.12.4), we have no own property with this name and our
  proto's property is writable and we're extensible, so [[CanPut]] returns true.
* Back in [[Put]] step 2 returns no descriptor since we have no property of that
  name.  Then step 3 is skipped.  Step 4 returns a data descriptor from the
  proto.  So step 5 is skipped, and step 6 should create a new data property on
  O (the nodelist in our case) by calling [[DefineOwnProperty]].

That's the end of the ES bits.  WebIDL defines [[DefineOwnProperty]] at http://dev.w3.org/2006/webapi/WebIDL/#defineownproperty and we step through that:

* Step 2 is skipped because P is not an array index property name
* We enter step 3, because we have no [NamedPropertiesObject] and no [Unforgeable] around.
* In step 3.1, P is not a supported property name, so "creating" is true.
* We enter step 3.2 because we have no own property named P
* Creating is true, so 3.2.1 is skipped.
* Creating is true and we have no named property creator, so 3.2.2 is skipped.
* We land in step 4, which calls the default [[DefineOwnProperty]]
This is fixed with the WebIDL bindings.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Depends on: 791774
Resolution: --- → FIXED
Checked in the test: https://hg.mozilla.org/integration/mozilla-inbound/rev/7e94ee1930f4
Flags: in-testsuite+
Stole this test:

https://dvcs.w3.org/hg/webapps/rev/f5a27cc10989

Comment 4

5 years ago
https://hg.mozilla.org/mozilla-central/rev/7e94ee1930f4
You need to log in before you can comment on or make changes to this bug.