The API specifies that convertToType may opt not to handle a conversion:
"@result The objects's converted value, or NULL if the object was not converted."
In which case, it would propagate first up the JSClass hierarchy, calling its superclass's conversion functions, and failing that call the
Unfortunately this behaviour was removed in bug#69677/bug#69858, and instead we now rely on the toStringCallback/valueOfCallback function introduced in bug#69156. Even after a fix in bug#73368, these will return the result from the first convertToType they find, regardless of whether this result is null, and if no convertToType method is found in the api class hierarchy (possible if toStringCallback/valueOfCallback was accessed off the prototype chain), they will also return a null pointer. This is unsafe.
It would be easy to make the approach based around toStringCallback/valueOfCallback continue to walk the api class hierarchy, but making the fallback to defaultValue would be problematic (since defaultValue calls toStringCallback/valueOfCallback, this would infinitely recurse). Making the fallback work with toString/valueOf methods attached to api objects is probably not the right thing to do – instead, we should just implement the defaultValue trap for api objects.
oops, "and failing that call the" JSObject::defaultValue function.
Created attachment 132485 [details]
Comment on attachment 132485 [details]
Can you add an additional test to testapi to verify that we don't crash on a convertToType function returning null?
Fixed in r111162