Bug 49218

Summary: WebIDL conversions from string to number and array to number should not generate TypeError
Product: WebKit Reporter: Gregg Tavares <gman>
Component: WebCore JavaScriptAssignee: Kenneth Russell <kbr>
Status: RESOLVED FIXED    
Severity: Normal CC: cmarrin, dglazkov, enne, jamesr, kbr, krit, oliver, zimmermann, zmo
Priority: P1    
Version: 528+ (Nightly build)   
Hardware: All   
OS: All   
Attachments:
Description Flags
Patch dglazkov: review+, kbr: commit-queue-

Gregg Tavares
Reported 2010-11-08 16:00:28 PST
If I you have a WebIDL function defined like this void stencilMask(long mask); According the the WebIDL spec, values passed as the "mask" argument are converted to a number by the spec defined in ECMAScript ToNumber in section 9. http://www.ecma-international.org/publications/standards/Ecma-262.htm That spec appears to say that strings are converted to numbers by calling ToNumber on the string which returns a number or NaN and in the case of an integral type, NaN is converted to 0. That means gl.stencilMask("123") should be the same as gl.stencilMask(123) and gl.stencilMask("bar") should be the same as gl.stencilMask(0); For objects it says first toString is called on the object, then that string is passed toNumber. Since an array is a type of object that means means that gl.stencilMask([123]) is the same as gl.stencilMask(123); All of these cases are currently returning TypeError in WebKit. Please read the WebIDL spec and ECMAScript spec to verify http://www.w3.org/TR/WebIDL/ Section 4.1.7 says long calls ToInt32 Section 4 says ToInt32 is defined in the EMCAScript spec. ECMAScript spec Section 9.5 says ToInt32 calls ToNumber Seciton 9.3 says ToNumber calls ToString on strings and ToNumber(ToPrimitve()) on objects. Section 9.1 says ToPrimitive uses the DefaultValue for objects Section 8.12.8 says default value is derived by calling toString() on the object.
Attachments
Patch (140.36 KB, patch)
2010-11-15 21:28 PST, Kenneth Russell
dglazkov: review+
kbr: commit-queue-
Gregg Tavares
Comment 1 2010-11-11 11:30:21 PST
I think I tracked this down to http://trac.webkit.org/changeset/70410 http://trac.webkit.org/changeset/70411 http://trac.webkit.org/changeset/70414 I downloaded r70429 which fails where as r70284 passes You can see this issue by going to this page https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/sdk/tests/conformance/type-conversion-test.html If you scroll down the results of the tests, on WebKit r70429 and greater (top of tree) more than half the tests fail. On r70284 or before almost all the tests pass. I don't know what other WebIDL generated APIs were effected by this.
Nikolas Zimmermann
Comment 2 2010-11-12 00:42:52 PST
(In reply to comment #1) > I think I tracked this down to > > http://trac.webkit.org/changeset/70410 > http://trac.webkit.org/changeset/70411 > http://trac.webkit.org/changeset/70414 > > I downloaded r70429 which fails where as r70284 passes > > You can see this issue by going to this page > > https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/sdk/tests/conformance/type-conversion-test.html > > If you scroll down the results of the tests, on WebKit r70429 and greater (top of tree) more than half the tests fail. On r70284 or before almost all the tests pass. > > I don't know what other WebIDL generated APIs were effected by this. That's true I changed the behaviour, but I wasn't aware I was breaking something, as these webgl tests are not in our LayoutTests/ framework. I'll look into unbreaking.
Kenneth Russell
Comment 3 2010-11-15 14:53:57 PST
Because we need this fixed urgently for a Chrome milestone release I'm taking this bug. Nikolas, please let me know if you had made progress on it already.
Kenneth Russell
Comment 4 2010-11-15 21:28:42 PST
Dimitri Glazkov (Google)
Comment 5 2010-11-15 21:57:28 PST
Comment on attachment 73958 [details] Patch looks good.
Nikolas Zimmermann
Comment 6 2010-11-15 22:47:26 PST
(In reply to comment #3) > Because we need this fixed urgently for a Chrome milestone release I'm taking this bug. Nikolas, please let me know if you had made progress on it already. Thanks a lot Kenneth, I'm just moving flats and thus a bit busy... Thanks also for catching several bugs in the SVG primitive tests! Great, that it's now fixed!
Dirk Schulze
Comment 7 2010-11-15 22:56:21 PST
IIRC we don't check for NaN values in the SVG*Element.cpp files. This could cause problems! I don't have examples right now. But I could imagine that there are cases, it needs at least checking. Niko?
Nikolas Zimmermann
Comment 8 2010-11-15 23:10:43 PST
(In reply to comment #7) > IIRC we don't check for NaN values in the SVG*Element.cpp files. This could cause problems! I don't have examples right now. But I could imagine that there are cases, it needs at least checking. Niko? Absolutely true. Though note, that Kenneth just restored the "old" behaviour, that existed prior to my StrictTypeChecking changes. The NaN cases are now possible again, and as it's even correct according to WebIDL/ECMA, we need to add lots of more checks into the whole svg/ code regarding numeric value interpretation.
Kenneth Russell
Comment 9 2010-11-16 11:19:38 PST
Note You need to log in before you can comment on or make changes to this bug.