What's the signature of your cardPropertySetTimeout function? It's a bit odd that it's not being called at all; I'd not be surprised if it's being called incorrectly...
Created attachment 531938 [details] A very simple test file demonstrating the problem If you run this very simple test you will see that the constructor and the getter is called once, but the setter is never called.
The signature is: static JSBool cardPropertySetTimeout(JSContext *cx, JSObject *obj, jsid id, JSBool strict, jsval *vp) I have submitted a very simple test program that demonstrates the problem.
Hmm. Yeah, that should all work.... Are you just running pure interp with no jit?
Status: UNCONFIRMED → NEW
Ever confirmed: true
I agree it should work, but it doesn't. Could someone please try running my simple test to verify? I am running on a WIN32 build with all the default options plus --enable-threadsafe --enable-trace-jscalls. I agree it is very strange that this feature is failing. I have run quite a few tests and the setter callback from the JSPropertySpec table is never called.
Does the problem go away if you take out the "JSOPTION_JIT | JSOPTION_METHODJIT" jscontext options?
> Does the problem go away if you take out the "JSOPTION_JIT | > JSOPTION_METHODJIT" jscontext options? No. Exactly the same result.
Does the setter get called if you do not run the getter before that? So in this code: c = new Card(); c.timeout = 10;
If I run: c = new Card(); c.timeout = 10; the setter is still not called.
Hmm. So if you add JSPROP_SHARED for that property, do things work?
> Hmm. So if you add JSPROP_SHARED for that property, do things work? Yes, but I don't know what the side effects of adding JSPROP_SHARED are. I realize that this may be a workaround, but it seems to me to be a kludge solution.
The engine is behaving correctly. Add JSPROP_SHARED if you want the property to behave like an ES5 accessor property. (That API oddity probably predates ES5 by ten years, so there's little we can do about it now.) The consequences of adding JSPROP_SHARED are: - assigning to the property on an object that inherits the property from a prototype calls the setter (exactly the behavior you want) - no field is allocated for the property - "the shared permanent hack", a bit of obscure legacy oddness which you can ignore, since this property is not also JSPROP_PERMANENT.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → INVALID
P.S. Thank you for providing a complete test case. I was able to figure out what was going on in a few minutes because of that. Otherwise this would never have been resolved.
Thank you for the help in resolving this problem. In order to make the conversion from JS 1.7 to JS 1.8.5, I would like to suggest that this change be documented in the 1.8.5 release notes and that the JSPropertySpec documentation specify when the setter is called.
Jason, the weird thing here is the behavior change and the fact that presumably scripted setters on the proto _do_ get run.... or do those get defined as JSPROP_SHARED?
Scripted setters get defined with JSPROP_SHARED.
That there was a behavior change is surprising to me. I thought it had always worked this way. Jeff, did we change something in the FF4 timeframe, maybe when straightening up ES5 accessor behavior?
I'm not aware of any such change, but seemingly something did change, and that's as plausible a guess as anything.
You need to log in before you can comment on or make changes to this bug.