[Webkit-unassigned] [Bug 40012] Callable objects created via JavaScriptCore API cannot be used as Geolocation callbacks

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Jun 1 15:32:36 PDT 2010


https://bugs.webkit.org/show_bug.cgi?id=40012





--- Comment #1 from Gavin Barraclough <barraclough at apple.com>  2010-06-01 15:32:35 PST ---
(In reply to comment #0)
> Geolocation specification requires that only "Function objects" can be used for Geolocation callbacks. We currently require the callback to inherit from JSFunction, which is almost definitely incorrect, because this doesn't include functions created via API.
> 
> In JSC, there are two ways to check for being callable:
> 1) Check callData return value. That's the closest to just trying to call the object, but it includes RegExp objects, which we may or may not want to exclude;
> 2) Check that className is "Function". That seems to match the current WebIDL text best, but it doesn't cover objects created via API.

I'd suggest the best check here would be to test that the value is callable, but is not a regexp - i.e.:
    ((value.getCallData() != CallTypeNone) && !value.inherits(&RegExpObject::info))
Generally speaking, the ECMA spec requires a 1-1 correlation between objects being callable and considered a function – regexps are one class where we follow other browsers in make an exception to this rule (not doing so breaks the web).

> The reason for the spec requirement is reportedly to disallow objects with handleEvent property, and that makes sense, because the callbacks aren't events. But Geolocation shouldn't really be different from Database or other APIs that have callbacks. Web APIs don't check for callback argument types upfront (I actually suspect that a JS object can even become callable - or cease to be callable - at some point after creation, making upfront checks inadequate).

Whether an object is or is not callable is not statically typed – it is determined by the result of a virtual function call.  The are no restrictions to ensure that for a given object the result is repeatable – but that said, I can't think of any example of an object where this would change.  The only classes I can think that may produce more than one result would be JSFunction (CallTypeJS or CallTypeHost) and API objects (CallTypeNone or CallTypeHost) - but in both cases this should be fixed from object creation.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.


More information about the webkit-unassigned mailing list