[webkit-dev] js binding: function argument type checking

Sam Weinig sam.weinig at gmail.com
Wed Aug 11 22:26:47 PDT 2010


For this specific case, it seems like you could easily check for a null
WebGLProgram* in WebGLRenderingContext::useProgram and set the
ExceptionCode.

-Sam

On Wed, Aug 11, 2010 at 8:54 PM, Mo, Zhenyao <zhenyao at gmail.com> wrote:

> For example,
>
>    webgl.useProgram("foo");
>
> This should throw an error.  However, current behavior will execute
>
>    webgl.useProgram(null)
>
> instead, which will run through without even generating an gl error.
>
> I saw a few TYPE_MISMATCH_ERROR in custom-binding.  To me, whether
> it's TYPE_MISMATCH_ERROR or TypeError is less important, but
> generating an error is.
>
> On Wed, Aug 11, 2010 at 8:14 PM, Sam Weinig <sam.weinig at gmail.com> wrote:
> > I am not sure this is true across the board, in many places we set the
> > exception code to TYPE_MISMATCH_ERR on null input in the implementation
> (the
> > first one I looked at was CanvasRenderingContext2D::drawImage). Can you
> go
> > into more detail about why the WebGL bindings need to be more strict than
> > the rest of the codebase?
> > -Sam
> >
> > On Wed, Aug 11, 2010 at 7:06 PM, Mo, Zhenyao <zhenyao at gmail.com> wrote:
> >>
> >> Currently for a function's signature in WebKit, if an argument's type
> >> is a wrapper type (those JS objec ts that wrap c++ objects, for
> >> example, JSWebGLProgram, JSCSSRule, etc.) and if the input object's
> >> type does not match the signature, the input is casted to null and no
> >> TypeError is raised.
> >>
> >> Even though WebKit doesn't use Web IDL specially, I think we can look
> >> to the Web IDL spec for guidance on what the behavior should be.
> >> According to Web IDL spec (http://dev.w3.org/2006/webapi/WebIDL/),
> >> unless [AllowAny] is put in the signature, an TypeError should be
> >> raised if an argument type does not match its signature.  The new
> >> automatic code generation for overloaded functions in WebKit DOES
> >> raise TypeError when it fails to determine which overloaded variant to
> >> call.
> >>
> >> We definitely need to do the strict type checking for WebGL functions.
> >>  However, changing the default behavior of the IDL code generators
> >> might have a significant compatibility impact. It isn't clear to us
> >> whether the current behavior is intentional.  If yes, please let us
> >> know and we will try to fix the WebGL part only.  Otherwise we will
> >> modify the general rule instead.
> >> _______________________________________________
> >> webkit-dev mailing list
> >> webkit-dev at lists.webkit.org
> >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20100811/2d92d51f/attachment.html>


More information about the webkit-dev mailing list