Created attachment 460437 [details] [diff] [review] fix This was regressed by fatval which passes ®s.sp[x] instead of passing the address of a copy to setProperty.
Attachment #460437 - Flags: review?(brendan)
Comment on attachment 460437 [details] [diff] [review] fix Whew! Thanks to adrake for noticing, Waldo for escalating, and Luke for patching. A trace-test is enough in my book but a purist might want an ecma_1 jsreftest. /be
Attachment #460437 - Flags: review?(brendan) → review+
This was covered (badly) by ACID3, before we optimized JSOP_LENGTH, Waldo says. /be
In fairness to Acid3, I'm not sure there's any other property native to ECMAScript-262, 3rd ed. which has this sort of magical coerc-y behavior upon setting (and ES5 was out because of the self-imposed restriction to long-standardized functionality). From what I can tell only Array had a magical [[Put]] implementation which did anything other than set to the provided value. /a/.lastIndex comes close, but ES3 underspecified it enough that it's better the exact spec language wasn't lawyered into something convolutedly semi-self-consistent. The E4X examples here are out for obvious reasons. And ES5 getters and setters using either literal or programmatic syntax didn't even exist at that point in a standard, or their semantics were yet far from being worked out. It hadn't occurred to me that length wasn't optimized when bug 312354 was fixed -- an example for people writing tests of why tests should address both general (some random property name, in concert with our then-extension-land setters) and specific cases (like length as Acid3 exercised) rather than the narrow bit suggested by a testcase.
Hah! if Hixie could test SMIL in Acid3, then E4X was fair game too. Good point about generalized or wide-field-of-fire tests. /be
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.