Re: [webkit-dev] js binding: function argument type checking
Actually it's a different issue. What we want to do is not enforcing full arguments, but if an input argument is the wrong type, we raise a TypeError. Mo On Wed, Aug 11, 2010 at 7:13 PM, Adam Barth aba...@webkit.org wrote: This sounds related to the recent addition of [RequiresAllArguments=Raise]. Historically, we've been lax about missing arguments. I think the specs want us to be stricter, but last time we discussed the topic, the read I got was that the compatibility pain might not be worth the benefit. Adam On Wed, Aug 11, 2010 at 7:06 PM, Mo, Zhenyao zhen...@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@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] js binding: function argument type checking
The auto-generated code will look like If (argument.isUndefinedOrNull() == false toType(argument) == null) raise(TypeError); I really think we should do this universally. However, if there is a good reason we really shouldn't, please let us know. On Wed, Aug 11, 2010 at 11:10 PM, Mo, Zhenyao zhen...@gmail.com wrote: Actually it's a different issue. What we want to do is not enforcing full arguments, but if an input argument is the wrong type, we raise a TypeError. Mo On Wed, Aug 11, 2010 at 7:13 PM, Adam Barth aba...@webkit.org wrote: This sounds related to the recent addition of [RequiresAllArguments=Raise]. Historically, we've been lax about missing arguments. I think the specs want us to be stricter, but last time we discussed the topic, the read I got was that the compatibility pain might not be worth the benefit. Adam On Wed, Aug 11, 2010 at 7:06 PM, Mo, Zhenyao zhen...@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@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] js binding: function argument type checking
if converting a JS argument to the type declared in the IDL file throws an exception, the auto-generated code will throw a TYPE_MISMATCH_ERR. so i think we just need to change toJS/toV8 to throw exceptions when conversions fails instead of returning NULL (toString(), toInt32(), etc. already do that). dumi On Wed, Aug 11, 2010 at 11:10 PM, Mo, Zhenyao zhen...@gmail.com wrote: Actually it's a different issue. What we want to do is not enforcing full arguments, but if an input argument is the wrong type, we raise a TypeError. Mo On Wed, Aug 11, 2010 at 7:13 PM, Adam Barth aba...@webkit.org wrote: This sounds related to the recent addition of [RequiresAllArguments=Raise]. Historically, we've been lax about missing arguments. I think the specs want us to be stricter, but last time we discussed the topic, the read I got was that the compatibility pain might not be worth the benefit. Adam On Wed, Aug 11, 2010 at 7:06 PM, Mo, Zhenyao zhen...@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@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Build system complexity
Are there currently any plans for simplifying the situation regarding build systems? I haven't seen any threads for a while, which I assume means no. Is there any low hanging fruit out there? Since many of the build systems are little more than lists of files, it really seems like we should be able to do some sort of consolidation. Or reduce the process down to updating one file and then running a script that updates/generates the rest. Currently, I cringe every time I find out I need to add a new file. In addition, has anyone ever looked at simplifying the mac port's xcode project? It's _by far_ the heaviest burden on the project given that you pretty much need to use xcode (which is mac only...no other port requires this), exported linker symbols are in a separate file, extra effort to expose a new file in WTF to WebCore, extra effort to expose a new file in WebCore to WebKit, etc. Has anyone recently looked at how the mac build could be simplified--especially from the perspective of contributors whose main development platform isn't a mac? Thanks! Jeremy ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Build system complexity
In addition, has anyone ever looked at simplifying the mac port's xcode project? It's _by far_ the heaviest burden on the project given that you pretty much need to use xcode (which is mac only...no other port requires this), exported linker symbols are in a separate file, extra effort to expose a new file in WTF to WebCore, extra effort to expose a new file in WebCore to WebKit, etc. Has anyone recently looked at how the mac build could be simplified--especially from the perspective of contributors whose main development platform isn't a mac? i completely agree with jeremy. is it possible to at least drop the cryptic hashcodes/timestamps? without them, the .xcodeproj files should at least be editable by hand. dumi ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit blog post proposal: Remote debugging with Web Inspector.
On Aug 9, 2010, at 3:48 PM, ext Pavel Feldman wrote: Hi guys, As some of you know, we are working on a remote debugging feature in Web Inspector. There are many good reasons behind the project including the following: - Debugging WebKit on embedded devices - Shaping up a good protocol for ourselves - Introducing external SDKs on top of the protocol for IDE integrations and alternate front-ends We've had serialized interaction with the out-of-process inspector for quite a while in Chromium. We were upstreaming it into WebKit and have reached an important milestone recently: all the interaction between the inspected page and inspector is entirely serialized on the WebKit level. All the embedder needs to do is to implement a socket that would serve the inspector front-end files and provide our messaging with appropriate transport. Now this socket is likely to be platform-specific, implemented on the WebKit and/or host browser levels. It also makes more sense to implement socket on mobile platforms first. However, we've done a proof-of-concept implementation in Chromium and it is now in a demoable state! See the screencast at http://screencast.com/t/YTI2OTY4YTEt. It has Chromium nightly to the left + WebKit nightly to the right. WebKit nightly connects remotely to Chromium over HTTP on the port 9222 and does remote debugging including DOM inspection, breakpoints and such. The communication is established by means of a WebSocket. The interesting thing about the implementation is that inspector front-end is fetched from the host browser, so that there is no mess with protocol versioning and no need in exposing the interaction protocol any time soon. So I made the demo and it looked cool. I thought maybe we do a blog post on it. The blog post would draw attention to the Web Inspector and its progress, share the remote debugging vision with the interested parties and would simply look cool. Front-end is working as a pure HTML5 application (obviously full of WebKit-specific styles, but still) which is impressive. Now the project is nowhere complete in terms of finalizing the message format and the protocol itself, but there is no intention to expose it right now. We'd like to let it live with fetchable front-end and mature before we expose the protocol and commit to any level of interface support. What do you think, is it ready for a blog post? I think it is ready for a blog post. Nice work! I've been leveraging your work to make remote Web Inspector work in QtWebKit. I've also been working on exposing a ChromeDevTools / V8 debugger protocol backend so that we can use an Eclipse IDE for W3C Widget and Qt WRT debugging. The IDE debugger backend is structured as an alternate front-end for Web Inspector. I submitted several patches to enable that, and I think our debugger backend is getting to a state where I'm willing to post that code as well. Best regards, Jamey Hicks ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Build system complexity
On Aug 12, 2010, at 3:54 AM, Dumitru Daniliuc d...@chromium.org wrote: i completely agree with jeremy. is it possible to at least drop the cryptic hashcodes/timestamps? without them, the .xcodeproj files should at least be editable by hand. Doesn't gyp already generate Xcode projects for Chrome? I think the issue is that gyp can't generate replacement project files for Apple's Mac port or other build systems yet. That was my take-away from the last discussion--that gyp needed to be enhanced so that all build systems could be generated, making addition or removal of source files a trivial task. As far as Jeremy's other points, perhaps bugs should be filed about each item so that more specific discussion can take place on each topic. Dave ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] js binding: function argument type checking
That should work too. mo On Thu, Aug 12, 2010 at 3:24 AM, Dumitru Daniliuc d...@chromium.org wrote: so i think we just need to change toJS/toV8... sorry, i meant toClass(), not toJS/toV8. dumi On Wed, Aug 11, 2010 at 11:10 PM, Mo, Zhenyao zhen...@gmail.com wrote: Actually it's a different issue. What we want to do is not enforcing full arguments, but if an input argument is the wrong type, we raise a TypeError. Mo On Wed, Aug 11, 2010 at 7:13 PM, Adam Barth aba...@webkit.org wrote: This sounds related to the recent addition of [RequiresAllArguments=Raise]. Historically, we've been lax about missing arguments. I think the specs want us to be stricter, but last time we discussed the topic, the read I got was that the compatibility pain might not be worth the benefit. Adam On Wed, Aug 11, 2010 at 7:06 PM, Mo, Zhenyao zhen...@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@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Build system complexity
On Thu, Aug 12, 2010 at 7:18 AM, David Kilzer ddkil...@webkit.org wrote: On Aug 12, 2010, at 3:54 AM, Dumitru Daniliuc d...@chromium.org wrote: i completely agree with jeremy. is it possible to at least drop the cryptic hashcodes/timestamps? without them, the .xcodeproj files should at least be editable by hand. Doesn't gyp already generate Xcode projects for Chrome? I think the issue is that gyp can't generate replacement project files for Apple's Mac port or other build systems yet. That was my take-away from the last discussion--that gyp needed to be enhanced so that all build systems could be generated, making addition or removal of source files a trivial task. Chrome has been using GYP for some time and it's pretty stable. I suspect that anyone trying to port the Mac port's xcode project to it will run into some bugs and/or need to build some additional features into it, but it is quite stable. And the GYP guys are very friendly people though, so I bet they'd be happy to help with any such problems. It's also worth noting that GYP was designed from the start to allow a project to move over to it slowly (you can have custom projects depend on GYP projects and vice versa). But moving to GYP is definitely not the only way to solve this issue--and quite possibly not the best way. I suspect that there are also many smaller steps that could be taken that'd have a big impact. For example, coming up with ways to generate sane/informative error messages for when someone doesn't export some symbol/header file properly would awesome and doesn't require changing the entire build system. Or creating some script that can add files to the xcode project. J ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Build system complexity
Let me re-iterate (because even some co-workers are getting confused): I'm not secretly trying to get the mac port to start using GYP. (Or saying it's a bad idea either, mind you.) I'm just concerned that the process associated with adding a file (or adding a dependency between projects on the mac port) is out of hand--and has been for some time. And I'm hoping we can come to some sort of conclusion that'll start the project moving in the right direction--even if it's slowly. That's it. I promise! J On Thu, Aug 12, 2010 at 3:37 PM, Jeremy Orlow jor...@chromium.org wrote: On Thu, Aug 12, 2010 at 7:18 AM, David Kilzer ddkil...@webkit.org wrote: On Aug 12, 2010, at 3:54 AM, Dumitru Daniliuc d...@chromium.org wrote: i completely agree with jeremy. is it possible to at least drop the cryptic hashcodes/timestamps? without them, the .xcodeproj files should at least be editable by hand. Doesn't gyp already generate Xcode projects for Chrome? I think the issue is that gyp can't generate replacement project files for Apple's Mac port or other build systems yet. That was my take-away from the last discussion--that gyp needed to be enhanced so that all build systems could be generated, making addition or removal of source files a trivial task. Chrome has been using GYP for some time and it's pretty stable. I suspect that anyone trying to port the Mac port's xcode project to it will run into some bugs and/or need to build some additional features into it, but it is quite stable. And the GYP guys are very friendly people though, so I bet they'd be happy to help with any such problems. It's also worth noting that GYP was designed from the start to allow a project to move over to it slowly (you can have custom projects depend on GYP projects and vice versa). But moving to GYP is definitely not the only way to solve this issue--and quite possibly not the best way. I suspect that there are also many smaller steps that could be taken that'd have a big impact. For example, coming up with ways to generate sane/informative error messages for when someone doesn't export some symbol/header file properly would awesome and doesn't require changing the entire build system. Or creating some script that can add files to the xcode project. J ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Build system complexity
Hi Jeremy, On Aug 12, 2010, at 7:37 AM, Jeremy Orlow wrote: On Thu, Aug 12, 2010 at 7:18 AM, David Kilzer ddkil...@webkit.org wrote: On Aug 12, 2010, at 3:54 AM, Dumitru Daniliuc d...@chromium.org wrote: i completely agree with jeremy. is it possible to at least drop the cryptic hashcodes/timestamps? without them, the .xcodeproj files should at least be editable by hand. Doesn't gyp already generate Xcode projects for Chrome? I think the issue is that gyp can't generate replacement project files for Apple's Mac port or other build systems yet. That was my take-away from the last discussion--that gyp needed to be enhanced so that all build systems could be generated, making addition or removal of source files a trivial task. Chrome has been using GYP for some time and it's pretty stable. I suspect that anyone trying to port the Mac port's xcode project to it will run into some bugs and/or need to build some additional features into it, but it is quite stable. And the GYP guys are very friendly people though, so I bet they'd be happy to help with any such problems. It's also worth noting that GYP was designed from the start to allow a project to move over to it slowly (you can have custom projects depend on GYP projects and vice versa). But moving to GYP is definitely not the only way to solve this issue--and quite possibly not the best way. I suspect that there are also many smaller steps that could be taken that'd have a big impact. For example, coming up with ways to generate sane/informative error messages for when someone doesn't export some symbol/header file properly would awesome and doesn't require changing the entire build system. Or creating some script that can add files to the xcode project. One project I've been meaning to hack on once I take care of some higher priority work I'm doing is to update WebKitTools/Scripts/update-sources-list.py to pull sources from GYP instead of the code in there to pull sources from (now defunct) Bakefile build system. The idea here is that we can make changes to the source list in one place (say, the GYP files), then run this script and it will update the file lists for other ports that use text-based lists, like GTK, Qt and any ports using CMake. This I think would make updating a lot more straightforward and reduce the need for manually making the same change in 6 different build systems. Adding XCode and MSVC support certainly would be possible too, but if ports using those files are still interested in doing a switch to GYP in the near future, it may not make much sense to bother with it. I've also been working on https://bugs.webkit.org/show_bug.cgi?id=27551, which would allow us to stop using export symbol definition files and instead have the export info in the headers instead, so that all ports can use them rather than having each port define its own export symbols file. That's another thing that I think could reduce a lot of redundant maintenance. Regards, Kevin J ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] js binding: function argument type checking
On Wed, Aug 11, 2010 at 10:58 PM, Darin Fisher da...@chromium.org wrote: On Wed, Aug 11, 2010 at 10:37 PM, Sam Weinig sam.wei...@gmail.com wrote: On Wed, Aug 11, 2010 at 10:29 PM, Cedric Vivier cedr...@neonux.comwrote: On Thu, Aug 12, 2010 at 13:26, Sam Weinig sam.wei...@gmail.com wrote: For this specific case, it seems like you could easily check for a null WebGLProgram* in WebGLRenderingContext::useProgram and set the ExceptionCode. Nope, null is a valid argument, it bounds to the initial program, which means nothing will be drawn with WebGL. Certainly not the expected behavior when one pass the wrong type to the argument like Zhenyao pointed out, therefore throwing TypeError really makes sense here (and elsewhere with WebGL API). Ok, in that case, it seems like you need to do it in the bindings for this. I would prefer not making a sweeping change at this time, and instead keeping the changes just to places where the extra checking is necessary due to ambiguity (as in this useProgram case). -Sam Out of curiosity, if we have the ability for code to be auto generated from the IDL, why not use it universally? I'm trying to guess to understand your preference :) -Darin My concern with doing it universally is the performance cost of doing the check twice in many places (once in the bindings and once in the implementation with a null check). We could certainly re-evaluate the way we do these type checks, potentially even converting the existing null checks in the implementation to asserts, but I think that discussion shouldn't be conflated with this bug fix. -Sam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Build system complexity
Eric and I discussed this recently. We think the easiest path forward is to try to remove build systems incrementally. Each build system we remove makes it easier to hack on the project because you have one less build system to worry about. The easiest build system to remove is probably the Visual Studio build system. There's some complexity there because several ports use the vcproj files (e.g., apple-win, win-cairo, and wince as I recall). My understanding (based on past emails) is that either CMake or GYP would be workable. I'm not sure there's anything blocking this work. We just need someone to be interested enough in making it happen to do it. Adam On Thu, Aug 12, 2010 at 2:53 AM, Jeremy Orlow jor...@chromium.org wrote: Are there currently any plans for simplifying the situation regarding build systems? I haven't seen any threads for a while, which I assume means no. Is there any low hanging fruit out there? Since many of the build systems are little more than lists of files, it really seems like we should be able to do some sort of consolidation. Or reduce the process down to updating one file and then running a script that updates/generates the rest. Currently, I cringe every time I find out I need to add a new file. In addition, has anyone ever looked at simplifying the mac port's xcode project? It's _by far_ the heaviest burden on the project given that you pretty much need to use xcode (which is mac only...no other port requires this), exported linker symbols are in a separate file, extra effort to expose a new file in WTF to WebCore, extra effort to expose a new file in WebCore to WebKit, etc. Has anyone recently looked at how the mac build could be simplified--especially from the perspective of contributors whose main development platform isn't a mac? Thanks! Jeremy ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Build system complexity
An added benefit of removing the VS build system first would be that we'd be able to build using VS2005 or VS2008. On Thu, Aug 12, 2010 at 10:36 AM, Adam Barth aba...@webkit.org wrote: Eric and I discussed this recently. We think the easiest path forward is to try to remove build systems incrementally. Each build system we remove makes it easier to hack on the project because you have one less build system to worry about. The easiest build system to remove is probably the Visual Studio build system. There's some complexity there because several ports use the vcproj files (e.g., apple-win, win-cairo, and wince as I recall). My understanding (based on past emails) is that either CMake or GYP would be workable. I'm not sure there's anything blocking this work. We just need someone to be interested enough in making it happen to do it. Adam On Thu, Aug 12, 2010 at 2:53 AM, Jeremy Orlow jor...@chromium.org wrote: Are there currently any plans for simplifying the situation regarding build systems? I haven't seen any threads for a while, which I assume means no. Is there any low hanging fruit out there? Since many of the build systems are little more than lists of files, it really seems like we should be able to do some sort of consolidation. Or reduce the process down to updating one file and then running a script that updates/generates the rest. Currently, I cringe every time I find out I need to add a new file. In addition, has anyone ever looked at simplifying the mac port's xcode project? It's _by far_ the heaviest burden on the project given that you pretty much need to use xcode (which is mac only...no other port requires this), exported linker symbols are in a separate file, extra effort to expose a new file in WTF to WebCore, extra effort to expose a new file in WebCore to WebKit, etc. Has anyone recently looked at how the mac build could be simplified--especially from the perspective of contributors whose main development platform isn't a mac? Thanks! Jeremy ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] js binding: function argument type checking
Hardly. Right now we already do the type checking in the generated toType(argument) functions. Instead of casting to null, we throw a TypeError, which adds no extra cost if the type is correct. Besides, where I looked, after toType(argument) call, exception is checked. Only that currently toType(argument) is not generating exceptions. Mo On Thu, Aug 12, 2010 at 9:20 AM, Sam Weinig sam.wei...@gmail.com wrote: On Wed, Aug 11, 2010 at 10:58 PM, Darin Fisher da...@chromium.org wrote: On Wed, Aug 11, 2010 at 10:37 PM, Sam Weinig sam.wei...@gmail.com wrote: On Wed, Aug 11, 2010 at 10:29 PM, Cedric Vivier cedr...@neonux.com wrote: On Thu, Aug 12, 2010 at 13:26, Sam Weinig sam.wei...@gmail.com wrote: For this specific case, it seems like you could easily check for a null WebGLProgram* in WebGLRenderingContext::useProgram and set the ExceptionCode. Nope, null is a valid argument, it bounds to the initial program, which means nothing will be drawn with WebGL. Certainly not the expected behavior when one pass the wrong type to the argument like Zhenyao pointed out, therefore throwing TypeError really makes sense here (and elsewhere with WebGL API). Ok, in that case, it seems like you need to do it in the bindings for this. I would prefer not making a sweeping change at this time, and instead keeping the changes just to places where the extra checking is necessary due to ambiguity (as in this useProgram case). -Sam Out of curiosity, if we have the ability for code to be auto generated from the IDL, why not use it universally? I'm trying to guess to understand your preference :) -Darin My concern with doing it universally is the performance cost of doing the check twice in many places (once in the bindings and once in the implementation with a null check). We could certainly re-evaluate the way we do these type checks, potentially even converting the existing null checks in the implementation to asserts, but I think that discussion shouldn't be conflated with this bug fix. -Sam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] js binding: function argument type checking
For what it's worth, I think this change should be made for all of the DOM bindings, not just those for WebGL. The IDL code generators' support for overloaded methods already generates TypeError when an incoming argument doesn't implement any of the interfaces required by the overloaded variants. The new behavior will be closer to the rules specified by Web IDL in http://dev.w3.org/2006/webapi/WebIDL/#es-interface and also, as I understand it, closer to what Firefox implements. It would be possible to add support for another extended attribute to the code generators and annotate all of the methods in WebGLRenderingContext.idl, but I really think the default behavior should be changed. -Ken On Thu, Aug 12, 2010 at 1:15 PM, Mo, Zhenyao zhen...@gmail.com wrote: Hardly. Right now we already do the type checking in the generated toType(argument) functions. Instead of casting to null, we throw a TypeError, which adds no extra cost if the type is correct. Besides, where I looked, after toType(argument) call, exception is checked. Only that currently toType(argument) is not generating exceptions. Mo On Thu, Aug 12, 2010 at 9:20 AM, Sam Weinig sam.wei...@gmail.com wrote: On Wed, Aug 11, 2010 at 10:58 PM, Darin Fisher da...@chromium.org wrote: On Wed, Aug 11, 2010 at 10:37 PM, Sam Weinig sam.wei...@gmail.com wrote: On Wed, Aug 11, 2010 at 10:29 PM, Cedric Vivier cedr...@neonux.com wrote: On Thu, Aug 12, 2010 at 13:26, Sam Weinig sam.wei...@gmail.com wrote: For this specific case, it seems like you could easily check for a null WebGLProgram* in WebGLRenderingContext::useProgram and set the ExceptionCode. Nope, null is a valid argument, it bounds to the initial program, which means nothing will be drawn with WebGL. Certainly not the expected behavior when one pass the wrong type to the argument like Zhenyao pointed out, therefore throwing TypeError really makes sense here (and elsewhere with WebGL API). Ok, in that case, it seems like you need to do it in the bindings for this. I would prefer not making a sweeping change at this time, and instead keeping the changes just to places where the extra checking is necessary due to ambiguity (as in this useProgram case). -Sam Out of curiosity, if we have the ability for code to be auto generated from the IDL, why not use it universally? I'm trying to guess to understand your preference :) -Darin My concern with doing it universally is the performance cost of doing the check twice in many places (once in the bindings and once in the implementation with a null check). We could certainly re-evaluate the way we do these type checks, potentially even converting the existing null checks in the implementation to asserts, but I think that discussion shouldn't be conflated with this bug fix. -Sam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] js binding: function argument type checking
As I mentioned, I am not necessarily against ever changing the behavior, but if we do, we should make sure to remove all the existing checks, as they become an unnecessary branch. It just seems to me like that should be a separate change than a bug due to ambiguity. -Sam On Thu, Aug 12, 2010 at 4:21 PM, Kenneth Russell k...@google.com wrote: For what it's worth, I think this change should be made for all of the DOM bindings, not just those for WebGL. The IDL code generators' support for overloaded methods already generates TypeError when an incoming argument doesn't implement any of the interfaces required by the overloaded variants. The new behavior will be closer to the rules specified by Web IDL in http://dev.w3.org/2006/webapi/WebIDL/#es-interface and also, as I understand it, closer to what Firefox implements. It would be possible to add support for another extended attribute to the code generators and annotate all of the methods in WebGLRenderingContext.idl, but I really think the default behavior should be changed. -Ken On Thu, Aug 12, 2010 at 1:15 PM, Mo, Zhenyao zhen...@gmail.com wrote: Hardly. Right now we already do the type checking in the generated toType(argument) functions. Instead of casting to null, we throw a TypeError, which adds no extra cost if the type is correct. Besides, where I looked, after toType(argument) call, exception is checked. Only that currently toType(argument) is not generating exceptions. Mo On Thu, Aug 12, 2010 at 9:20 AM, Sam Weinig sam.wei...@gmail.com wrote: On Wed, Aug 11, 2010 at 10:58 PM, Darin Fisher da...@chromium.org wrote: On Wed, Aug 11, 2010 at 10:37 PM, Sam Weinig sam.wei...@gmail.com wrote: On Wed, Aug 11, 2010 at 10:29 PM, Cedric Vivier cedr...@neonux.com wrote: On Thu, Aug 12, 2010 at 13:26, Sam Weinig sam.wei...@gmail.com wrote: For this specific case, it seems like you could easily check for a null WebGLProgram* in WebGLRenderingContext::useProgram and set the ExceptionCode. Nope, null is a valid argument, it bounds to the initial program, which means nothing will be drawn with WebGL. Certainly not the expected behavior when one pass the wrong type to the argument like Zhenyao pointed out, therefore throwing TypeError really makes sense here (and elsewhere with WebGL API). Ok, in that case, it seems like you need to do it in the bindings for this. I would prefer not making a sweeping change at this time, and instead keeping the changes just to places where the extra checking is necessary due to ambiguity (as in this useProgram case). -Sam Out of curiosity, if we have the ability for code to be auto generated from the IDL, why not use it universally? I'm trying to guess to understand your preference :) -Darin My concern with doing it universally is the performance cost of doing the check twice in many places (once in the bindings and once in the implementation with a null check). We could certainly re-evaluate the way we do these type checks, potentially even converting the existing null checks in the implementation to asserts, but I think that discussion shouldn't be conflated with this bug fix. -Sam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Throwing SECURITY_ERR on cross-origin window.location property accesses
I was wondering if it would be a reasonable change to make accessing location.href (and other location properties) throw SECURITY_ERR when accessed across origins (https://webkit.org/b/43504). This initially was reported on the Chrome side (http://crbug.com/17325), but it looks like neither the JSC nor V8 bindings do this, so fixing it across the board seemed reasonable. From my investigations, it looks like IE and Gecko both throw an exception in this case, and the HTML5 spec mentions it too ( http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#security-location ). I realize that we're cautious around the access checks for security reasons (based on changes like https://trac.webkit.org/changeset/48619), but this seems safe since 1) we were returning control to the script at that point anyway 2) we already throw exceptions in some cases in that code: https://trac.webkit.org/browser/trunk/WebCore/bindings/js/JSLocationCustom.cpp#L219 Thanks, Mihai ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Throwing SECURITY_ERR on cross-origin window.location property accesses
Matching IE and FF means we shouldn't suffer too much in terms of incompatibilities. Of course, there could be some WebKit specific content out there that would break. This seems like a worthwhile change to try out. -Darin On Thu, Aug 12, 2010 at 8:08 PM, Mihai Parparita mih...@chromium.orgwrote: I was wondering if it would be a reasonable change to make accessing location.href (and other location properties) throw SECURITY_ERR when accessed across origins (https://webkit.org/b/43504). This initially was reported on the Chrome side (http://crbug.com/17325), but it looks like neither the JSC nor V8 bindings do this, so fixing it across the board seemed reasonable. From my investigations, it looks like IE and Gecko both throw an exception in this case, and the HTML5 spec mentions it too ( http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#security-location ). I realize that we're cautious around the access checks for security reasons (based on changes like https://trac.webkit.org/changeset/48619), but this seems safe since 1) we were returning control to the script at that point anyway 2) we already throw exceptions in some cases in that code: https://trac.webkit.org/browser/trunk/WebCore/bindings/js/JSLocationCustom.cpp#L219 Thanks, Mihai ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
