Object.prototype setter does not intercept a named store on an array (arr.zz = v creates an own key)
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 35/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- javascript, rust, typescript
- Domain
- compilers
Research direction
Start with the four-line repro: define a setter on Object.prototype, then assign a non-index key on an array and check whether the setter runs. The payload names only the array named-property store path and the existing plain-object gap test, not specific files, so locate the store path first. Done means the setter fires with 7 and no own key is created, matching node's output, and the plain-object case still passes.
Written by the indexing model from the issue text.
Description
An accessor (setter) defined on Object.prototype does not intercept a named-property store on an array. The store creates an own property instead of calling the setter.
let hit = 0;
Object.defineProperty(Object.prototype, "zz", { set(v) { hit = v; }, configurable: true });
const arr = [1, 2, 3];
arr.zz = 7;
console.log(hit, Object.prototype.hasOwnProperty.call(arr, "zz"));
// node: 7 false
// perry (as reported by the step 3 lane): setter not called, own key created
[[Set]] on an ordinary object (arrays included, for non-index keys) must find the inherited accessor along the whole prototype chain (Array.prototype, then Object.prototype) and call its setter.
This was found while building the object-model step 3 whole-chain key-add interception, where the gap test covers the plain-object case only. The array case is already broken on main and isn't caused by step 3. The fix belongs in the array named-property store path: answer interception from every hop of the chain, the same way the ordinary key-add path does.
- Dominant language
- Rust
- Stars
- 4.9k
- Forks
- 166
- Avg merge
- 1h 20m
- Merged PRs (30d)
- 915
Getting set up
- Ships a Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from PerryTS/perry
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
Maintainers usually reply within 1 day
-
Difficulty 3/5 1-2 days Newbie friendliness 70/100
Maintainers usually reply within 1 day
-
Difficulty 3/5 1-2 days Newbie friendliness 73/100
Maintainers usually reply within 1 day
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
Maintainers usually reply within 1 day
Similar issues
-
state:triage-needed
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
Maintainers usually reply within 1 day
-
bug P2
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
Maintainers usually reply within 1 day
-
cssparser-color: debug assertion in hsl_to_rgb for a hue that overflows f32Possibly taken @BartWaardenburg claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 64/100
servo/rust-cssparser#460 ·
-
`-w -r <range>` fails empty range but changed working treePossibly taken @dajiaohuang claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Maintainers usually reply within 2 days