Caused by attachment 268559 [details] [diff] [review] in bug 383269 comment 44 Expected value '33,42:33', Actual value '33,[object Object]:33'
I hate regressions but since finding them and getting them fixed gives my life meaning, nominating for 1.9.
Either call_resolve must resolve arguments whether or not JOF_ASSIGNING (aka JOF_SET) is set for JSOP_BINDNAME, or JSOP_BINDNAME should not have that flag in its opcode format. Independently, we should reduce redundant JOF_SET|...JOF_ASSIGNING to JOF_SET in jsopcode.tbl. /be
When a property becomes lazily bound *without JSPROP_SHARED* in a prototype via a class resolve hook, and that property has a setter (whether specialized or class setProperty hook, doesn't matter) that must run even when the property is being set in a delegating object (which normally shadows the proto-property, making its setter uninteresting), then resolve must not filter on JSRESOLVE_ASSIGNING. So I am going to attempt a minimal change to call_resolve and leave jsopcode.tbl alone until bug 407954 (someone please grab that, it's trivial but nice to have). /be
Created attachment 292644 [details] [diff] [review] minimal fix diff -w version next. Bob, could you please test this hard? I haven't got a good baseline and have other commitments, so could use a proof that this doesn't regress any fixed bugs. /be
(In reply to comment #4) > > Bob, could you please test this hard? can do today.
Fixed, optimizing for the case where the patch does indeed cause no regressions: js/src/jsfun.c 3.240 Please file a followup bug if there is an apparent regression. Thanks, /be
Looks good on the test tinderboxen for shell linux, macppc. I'll verify when I do better os coverage and have browser results.
verified fixed 1.9.0 Checking in public-failures.txt; /cvsroot/mozilla/js/tests/public-failures.txt,v <-- public-failures.txt new revision: 1.10; previous revision: 1.9 done