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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 > >> [email protected] > >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > > > >
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
