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
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] WebCore Build Times
would it be worth replacing #include wtf/*Ptr.h with #include wtf/Forward.h in all header files? On Tue, Jun 8, 2010 at 3:17 PM, Eric Seidel e...@webkit.org wrote: Has anyone spent any time trying to reduce the number of includes in WebCore? I know we have: https://trac.webkit.org/browser/trunk/WebKitTools/Scripts/find-extra-includes But I feel like we still have way too many unnecessary includes. I failed to find any tools for reducing build times or includes with my brief Google searching. But perhaps others have looked into this problem for WebKit or other projects? On my Intel Core 2 Duo MBP a full build takes over 1 hour. 5 years ago, on my g4 laptop a full build took around 40m. :( We seem to be slowly moving in the wrong direction. -eric ___ 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] Support FTS3 in WebSQLDatabases
Hi webkit-dev, I'd like to start a discussion about adding FTS3 support to WebSQLDatabases in WebKit. FTS3 has been a standard SQLite extension for quite some time and allows web developers to use full text search. The goal is to make it easier for web developers who used Gears for their apps to migrate those apps to HTML5 WebSQLDatabases. The amount of work to make this change should be minimal: a trivial WebKit change to allow FTS3 functions in SQL statements (I can take care of this), and rebuilding WebKit's SQLite library with FTS3 support on. Thanks, Dumi ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Support FTS3 in WebSQLDatabases
i've just opened https://bugs.webkit.org/show_bug.cgi?id=38003 to track this. dumi On Thu, Apr 22, 2010 at 1:15 PM, Brady Eidson beid...@apple.com wrote: I'd like to ask some of our SQLite gurus at Apple about this. I recall that they have had (admitedly Apple Internal) concerns about it in the past. Is there a bugzilla for this that I can follow and update? ~Brady On Apr 22, 2010, at 12:15 PM, Dumitru Daniliuc wrote: Hi webkit-dev, I'd like to start a discussion about adding FTS3 support to WebSQLDatabases in WebKit. FTS3 has been a standard SQLite extension for quite some time and allows web developers to use full text search. The goal is to make it easier for web developers who used Gears for their apps to migrate those apps to HTML5 WebSQLDatabases. The amount of work to make this change should be minimal: a trivial WebKit change to allow FTS3 functions in SQL statements (I can take care of this), and rebuilding WebKit's SQLite library with FTS3 support on. Thanks, Dumi ___ 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] upgrading sqlite library
it's a new test that i haven't submitted yet. sam: thanks for upgrading sqlite. i'm running that test right now. dumi On Fri, Mar 26, 2010 at 9:43 AM, Brady Eidson beid...@apple.com wrote: On Mar 25, 2010, at 5:34 PM, Dumitru Daniliuc wrote: (a HTML5 DB test fails 100% of the time in safari and DRT, but passes 100% of the time in chromium and as a standalone program linked directly to sqlite 3.4.2) What is the bugzilla for this? A test that should pass but fails 100% of the time in mainline WebKit is something we should be tracking to fix. ~Brady ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] upgrading sqlite library
my test still fails in safari/DRT. according to richard hipp, the patch that fixed this problem (http://www.sqlite.org/src/ci/256ec3c6af) was added to sqlite starting with version 3.6.16 (chromium uses 3.6.18, that's why the test passed there). i couldn't patch webkit's sqlite library, but i changed some webkit code to essentially do the same thing that the patch does and my test does pass in DRT/safari now. i will add my work-around to webkit, but it might be worth upgrading the library used by webkit and safari (and other ports should probably do the same) to a newer sqlite version. dumi On Fri, Mar 26, 2010 at 4:42 PM, Sam Weinig sam.wei...@gmail.com wrote: In fairness to Mark Rowe, he did the work. On Fri, Mar 26, 2010 at 12:32 PM, Dumitru Daniliuc d...@chromium.orgwrote: it's a new test that i haven't submitted yet. sam: thanks for upgrading sqlite. i'm running that test right now. dumi On Fri, Mar 26, 2010 at 9:43 AM, Brady Eidson beid...@apple.com wrote: On Mar 25, 2010, at 5:34 PM, Dumitru Daniliuc wrote: (a HTML5 DB test fails 100% of the time in safari and DRT, but passes 100% of the time in chromium and as a standalone program linked directly to sqlite 3.4.2) What is the bugzilla for this? A test that should pass but fails 100% of the time in mainline WebKit is something we should be tracking to fix. ~Brady ___ 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] upgrading sqlite library
hi, i have a few questions about the sqlite library that webkit uses: 1. what version is it? 2. is there any reason why we cannot upgrade it? 3. what would it take to upgrade it? is there a standard process that i could go through? it seems to me that webkit's sqlite library has some bugs that were fixed in a later version (a HTML5 DB test fails 100% of the time in safari and DRT, but passes 100% of the time in chromium and as a standalone program linked directly to sqlite 3.4.2), so i would like to build a newer library and see if that fixes the problem in safari and DRT; and if it does, push it to webkit. thanks, dumi ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Adding a vacuum() call to the Database class
Hi, I have just sent an email to public-webapps about adding a vacuum() call to the Database class: http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0771.html. If you have any comments or suggestions, please reply on either thread. Thanks, Dumi ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] storage/quota-tracking test failing on SnowLeopard
reposting from a different email. On Wed, Feb 10, 2010 at 1:17 PM, Dumitru Daniliuc d...@google.com wrote: i'm not sure why it's failing on snow leopard -- it seems to pass on all other platforms. i'll try to find a snow leopard machine today and debug it. sorry i haven't fixed this yet. dumi On Tue, Feb 9, 2010 at 2:19 PM, Darin Adler da...@apple.com wrote: Does anyone know why this test is failing? It’s failing on my computer as well as on the bot? -- Darin ___ 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] Boolean operators in if-statements: left side or right side?
According to http://webkit.org/coding/coding-style.html, rule #5 (and the check-webkit-style script), if-statements should look like this: if (a b) and not like this: if (a b) However, find WebCore/ -name *.cpp | xargs grep -E '^.*(|\|\|)\s*$' | wc -l = 925 incorrect uses find WebCore/ -name *.h | xargs grep -E '^.*(|\|\|)\s*$' | wc -l = 81 incorrect uses find WebCore/ -name *.cpp | xargs grep -E '^\s*(|\|\|).*$' | wc -l = 0 correct uses find WebCore/ -name *.h | xargs grep -E '^\s*(|\|\|).*$' | wc -l = 0 correct uses Should the rule be changed? Sorry if this was discussed already and I missed the thread. Thanks, Dumi ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Boolean operators in if-statements: left side or right side?
oops... sorry about that. after fixing the grep i get 831 (*.cpp) + 91 (*.h) correct uses, which makes much more sense. thanks, dumi On Tue, Feb 2, 2010 at 5:44 PM, Darin Adler da...@apple.com wrote: There’s something wrong with your grep. For example, this style is seen in RenderLineBoxList::paint. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Blacklisting some sqlite functions
in addition to these standard functions, we'd like to whitelist some functions from a few extensions chromium uses: full text search (fts2.c): whitelist snippet(), offsets(), optimize(), but not fts2_tokenizer(). unicode data (icu.c): whitelist regexp(), lower(), upper(), like(), but not icu_load_collation(). Is there any reason these are still Chromium-only? Even though we're having problems getting different vendors to agree on SQL dialect issues with the spec, I think we should make an effort to keep WebKit unified. FTS and ICU are sqlite standard extensions that live in the sqlite tree. Chromium compiles its own sqlite library and includes these 2 extensions; I'm not sure if they're included in WebKitLibraries/libWebCoreSQLite3.a though. I'm also going to forward this message on to some of our security colleagues at Apple, and we might have more feedback shortly. great, thanks! dumi ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Blacklisting some sqlite functions
while doing a security review of chromium's implementation of HTML5 DBs, chris noted that some sqlite functions are potential security risks. thus, we would like to blacklist them (or rather, have a list of whitelisted functions). currently, WebCore's sqlite authorizer allows all functions, but has a FIXME comment that wonders what the right thing to do is (WebCore/storage/DatabaseAuthorizer.cpp:281). here are the functions we'd like to whitelist: http://www.sqlite.org/lang_corefunc.html: all of them, except load_extension(), random() and randomblob() (once we fix some layout tests that currently use randomblob()). http://www.sqlite.org/lang_datefunc.html: all of them http://www.sqlite.org/lang_aggfunc.html: all of them in addition to these standard functions, we'd like to whitelist some functions from a few extensions chromium uses: full text search (fts2.c): whitelist snippet(), offsets(), optimize(), but not fts2_tokenizer(). unicode data (icu.c): whitelist regexp(), lower(), upper(), like(), but not icu_load_collation(). any objection? thanks, dumi ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Proposing style guide change regarding braces on conditional arms
While I personally believe every branch should be wrapped in braces, it seems like we're not going to get consensus on that. I can live with no braces on any branch, but mixing brace-wrapped branches and non-wrapped is really distasteful. So, I would vote for this suggestion, as it gets us closer to what I believe is good. +1 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
