Re: [webkit-dev] Trouble tracking down flaky test results ...
The test is logged as having failed: 2012-01-20 13:31:01,307 914 worker.py:180 DEBUG worker/9 compositing/geometry/limit-layer-bounds-transformed-overflow.html failed: 2012-01-20 13:31:01,307 914 worker.py:182 DEBUG worker/9 Text diff mismatch And the results zip file (http://build.chromium.org/f/chromium/layout_test_results/Webkit_Mac10_6__dbg_/118496/layout-test-results.zip) has a limit-layer-bounds-transformed-overflow-actual.txt file. The dashboard also displays the expected/actual/diff results: http://test-results.appspot.com/dashboards/flakiness_dashboard.html#showExpectations=truetests=compositing%2Fgeometry%2Flimit-layer-bounds-transformed-overflow.html Is there something else you're looking for? Mihai On Tue, Jan 24, 2012 at 9:52 AM, W. James MacLean wjmacl...@chromium.orgwrote: I'm trying to track down test results for a flaky layout test (compositing/geometry/limit-layer-bounds-transformed-overflow.html) on the Mac 10.6 bot at http://test-results.appspot.com/dashboards/flakiness_dashboard.html#tests=compositing%2Fgeometry%2Flimit-layer-bounds-transformed-overflow.html but each time I download the test results for one of the red slots (where presumably the test failed), the test is *never* in the list of failing tests (disclaimer: I haven't had to to try every set of test results, but I've randomly sampled about ten of them ...) Am I using the wrong method to find the results for a failing version of the test? James ___ 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] Trouble tracking down flaky test results ...
results.html only links unexpected failures, and this is an expected failure on Snow Leopard. Mihai On Tue, Jan 24, 2012 at 10:02 AM, W. James MacLean wjmacl...@chromium.orgwrote: I should add ... if I hunt through the raw directories in the results I can find the *actual* raw output, but it's not linked in via results.html (or so it seems). On Tue, Jan 24, 2012 at 12:52 PM, W. James MacLean wjmacl...@chromium.org wrote: I'm trying to track down test results for a flaky layout test (compositing/geometry/limit-layer-bounds-transformed-overflow.html) on the Mac 10.6 bot at http://test-results.appspot.com/dashboards/flakiness_dashboard.html#tests=compositing%2Fgeometry%2Flimit-layer-bounds-transformed-overflow.html but each time I download the test results for one of the red slots (where presumably the test failed), the test is *never* in the list of failing tests (disclaimer: I haven't had to to try every set of test results, but I've randomly sampled about ten of them ...) Am I using the wrong method to find the results for a failing version of the test? James ___ 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] Code Search for webkit.org
I usually search the copy of WebKit that's in the Chromium sub-index of code search. It's at most one day behind ToT WebKit (plus Code Search crawl/indexing delays): http://www.google.com/codesearch#search/exact_package=chromiumq=file%3A%5Esrc/third_party/WebKit Mihai Mihai On Fri, Sep 30, 2011 at 8:33 AM, Tom Zakrajsek t...@codeaurora.org wrote: codesearch seems very cool, but I noticed that http://codesearch.google.com/#**search/q=package:webkithttp://codesearch.google.com/#search/q=package:webkitseems to be picking up WebKit from the android repo at git:// android.git.kernel.org/**platform/external/webkit.githttp://android.git.kernel.org/platform/external/webkit.git. Does that cause problems with the code being stale (more stale than just using a cached copy)? Is there a way to get it to look at git:// git.webkit.org/WebKit.**git http://git.webkit.org/WebKit.git? --tom On 09/08/2011 03:34 PM, Dimitri Glazkov wrote: I3 codesearch. It's fast, and it's accurate. :DG On Thu, Sep 8, 2011 at 2:52 PM, Eric Seidele...@webkit.org wrote: I'm curious how other developers search the WebKit code? I use http://codesearch.google.com/#**search/q=package:webkithttp://codesearch.google.com/#search/q=package:webkitfrom time to time. If others do too, we should make it a redirect from cs.webkit.org (like we do for cia.webkit.org). Or maybe folks have better code search solutions? grep -r? -eric __**_ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/**mailman/listinfo.cgi/webkit-**devhttp://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-**devhttp://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-**devhttp://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] Some compile time data
Somewhat related to all this, if you'd like to keep an eye on your Xcode build times, you can use: $ defaults write com.apple.Xcode ShowBuildOperationDuration YES To have the build time show up in the status bar (at least with Xcode 3.x). Mihai On Mon, Apr 25, 2011 at 7:51 PM, Alexey Proskuryakov a...@webkit.org wrote: 25.04.2011, в 16:59, Stephanie Lewis написал(а): 12/trunk/Source/WebCore/bindings/scripts/CodeGeneratorJS.pm One way this can be optimized is by avoiding touching unchanged files. I believe that most of the time, modifications to the code generator don't change a lot of generated files. - WBR, Alexey Proskuryakov ___ 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] UA string changes blog draft
Hi Peter, I think you should say User Agent String in the title and maybe in the first paragraph say User Agent (UA) string, so that it's not quite as cryptic. The inline URLs are a bit ugly, perhaps some changes could be turned into a link to the tracking bug and similar changes in Firefox 4 could link to the mozilla.org post (and perhaps work in a link to http://blogs.msdn.com/b/ie/archive/2010/03/23/introducing-ie9-s-user-agent-string.aspx). Here’s some sample post-change UA strings: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_7; en-us) AppleWebKit/534.24 (KHTML, like Gecko) Version/5.0.3 Safari/534.24 Presumably the U and en-u should be removed from this line? The draft also has a lot of (presumably Google Docs-induced) inline styles that it may be a good idea to clean up. Mihai On Fri, Mar 25, 2011 at 10:53 AM, Peter Kasting pkast...@google.com wrote: On Fri, Mar 25, 2011 at 10:50 AM, Peter Kasting pkast...@google.com wrote: I've created a draft blog post at http://www.webkit.org/blog/?p=1580 about the recent changes I and others have made to the UA string. I'm interested in any feedback you might have. Note, since this is a draft, you need to log in to blog.webkit.org to see it (creating an account is simple and free). For those who haven't logged in or don't wish to, here's the current fulltext. PK --- UA String Changes On WebKit Trunk Posted by Peter Kasting on Friday, March 25th, 2011 at 10:44 am Recently some changes to the UA string (tracked by https://bugs.webkit.org/show_bug.cgi?id=54556) have landed. These changes are designed to add UA string detail, remove redundancy, and increase compatibility with Internet Explorer, and are happening in conjunction with similar changes in Firefox 4 (which you can read about at http://hacks.mozilla.org/2010/09/final-user-agent-string-for-firefox-4/). Here’s a few sample pre-change UA strings: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.19.4 (KHTML, like Gecko) Version/5.0.3 Safari/533.19.4 Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_7; en-us) AppleWebKit/534.16+ (KHTML, like Gecko) Version/5.0.3 Safari/533.19.4 Here’s some sample post-change UA strings: Mozilla/5.0 (Windows NT 6.0; WOW64) AppleWebKit/534.24 (KHTML, like Gecko) Version/5.0.3 Safari/534.24 Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_7; en-us) AppleWebKit/534.24 (KHTML, like Gecko) Version/5.0.3 Safari/534.24 In detail, the differences are as follows: On Windows, the initial “Windows;” platform identifier has been removed. This was redundant with the subsequent OS version identifier, and is more compatible with Internet Explorer, whose UA string doesn’t have this initial token. The “U” SSL encryption strength token has been removed. This token dates from more than a decade ago, when U.S. export laws limited the encryption strength that could be built into software shipped to various other countries; the valid values are ”U” (for “USA” 128-bit encryption support), “I” (for “International” 40-bit encryption support), and “N“ (for “None”, no encryption support). These days, it’s unusual to ship without 128-bit SSL support everywhere; ports can add “I” or “N” if necessary. On 64-bit versions of Windows, tokens have been added after the OS version. 32-bit builds running on 64-bit Windows have added “WOW64“. (”WOW64″ stands for “Windows 32-bit On Windows 64-bit” and is the name Microsoft gives its 32-bit compatibility subsystem.) 64-bit native builds use “Win64; x64” for x64-based processors and “Win64; IA64” for Itanium systems. These tokens are useful for sites that need to provide download links for native executables, and match what Internet Explorer uses. The locale has been removed. Web authors who want to know what languages a browser supports should use the HTTP Accept-Language header instead, which can supply multiple locales. Windows CE builds should report the OS version slightly more accurately (e.g. “Windows CE 5.1” instead of “Windows CE 5.x” or “Windows 5.1“). Google intends to ship Chrome 11 with these changes, assuming they don’t cause major web compatibility problems, in order to get them into place as soon as possible after the Firefox 4 and IE 9 launches, and is already testing them in Chrome Dev and Beta channel builds. ___ 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] Trouble with updating Chromium' slayout test expectations
It looks like Drew checked in baselines with http://trac.webkit.org/changeset/79034 (which may be why rebaseline-chromium-webkit-tests isn't doing anything, since it already has correct pixel baselines), but given http://trac.webkit.org/changeset/79088 it didn't seem to work. Drew, any ideas why? Mihai On Tue, Feb 22, 2011 at 2:07 AM, Hajime Morita morr...@google.com wrote: Hi Chromium WebKit folks, I'm looking for a help to retrieve the latest expectation files for Chromium Mac LayoutTest. At the weekend there was a change that triggers massive amount of pixel test failures that requires rebaselining. (https://bugs.webkit.org/b/54736) But the buildbot doesn't have the latest result for part of them, that means * rebaseline-chromium-webkit-tests doesn't update pixel results * [layout test results] links on buildbot dashboard are broken. Then now around 100 tests for Mac Chromium are left marked as failed (BUGWK54736 lines), waiting for their fresh expectations. Unfortunately I have no idea what's happening but missing 100 tests will possibly hurt us. How could I update these expectations? Any suggestions and/or helps are appreciated. Regards. -- morrita ___ 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] Trouble with updating Chromium' slayout test expectations
But these were rebaselines, which don't depend on any code changes. Mihai On Tue, Feb 22, 2011 at 10:35 AM, Mikhail Naganov mnaga...@chromium.org wrote: I have a suspicion that the cause of canaries failures is described here: https://groups.google.com/a/google.com/group/chrome-webkit-gardening/browse_thread/thread/d3b3a4fc647e804d In short, bots can run tests prematurely, emitting false failures. I observed this during my gardening, and I think you should check which revisions of WebKit and Chromium bots used while running tests. On Tue, Feb 22, 2011 at 20:16, Drew Wilson atwil...@google.com wrote: Yeah, it's weird. I rebaselined those tests, but the chromium canaries still showed them as red. Now, however, the canaries are showing many of them passing. I was planning to remove the lines from test_expectations today to see if they stay green. -atw On Tue, Feb 22, 2011 at 6:46 AM, Mihai Parparita mih...@chromium.org wrote: It looks like Drew checked in baselines with http://trac.webkit.org/changeset/79034 (which may be why rebaseline-chromium-webkit-tests isn't doing anything, since it already has correct pixel baselines), but given http://trac.webkit.org/changeset/79088 it didn't seem to work. Drew, any ideas why? Mihai On Tue, Feb 22, 2011 at 2:07 AM, Hajime Morita morr...@google.com wrote: Hi Chromium WebKit folks, I'm looking for a help to retrieve the latest expectation files for Chromium Mac LayoutTest. At the weekend there was a change that triggers massive amount of pixel test failures that requires rebaselining. (https://bugs.webkit.org/b/54736) But the buildbot doesn't have the latest result for part of them, that means * rebaseline-chromium-webkit-tests doesn't update pixel results * [layout test results] links on buildbot dashboard are broken. Then now around 100 tests for Mac Chromium are left marked as failed (BUGWK54736 lines), waiting for their fresh expectations. Unfortunately I have no idea what's happening but missing 100 tests will possibly hurt us. How could I update these expectations? Any suggestions and/or helps are appreciated. Regards. -- morrita ___ 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] Snow Leopard
The SL bot is now green (http://build.webkit.org/builders/SnowLeopard%20Intel%20Release%20(Tests)), ever since http://trac.webkit.org/changeset/79390 rolled out a change that resulted in all layout tests are crashing on Snow Leopard per the comment. It doesn't look like the cq has done a full cycle with a patch since then, perhaps it'll start landing patches now? Mihai On Tue, Feb 22, 2011 at 9:10 PM, Eric Seidel e...@webkit.org wrote: The SL bot has been broken since yesterday. Meaning the commit-queue is now up to 22 patches pending. There have been a couple media tests failing since checkin. But more concerning is there appears to be a marauding memory smasher: http://build.webkit.org/results/SnowLeopard%20Intel%20Release%20(WebKit2%20Tests)/r79391%20(8893)/results.html http://build.webkit.org/results/SnowLeopard%20Intel%20Release%20(WebKit2%20Tests)/r79388%20(8891)/results.html I don't have good data on when the memory smasher started. Maybe it's still fallout from Darin's utf8 decoder change? -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
Re: [webkit-dev] Web Inspector blog post draft
For those who are interested in this, I've included the draft inline below. Mihai Web Inspector: Styles Enhanced http://webkit.org/blog/?p=1463Posted by *Alexander Pavlov* on Wednesday, February 9th, 2011 at 9:43 am During the past months, we’ve been working hard to improve the CSS editing experience for the Web Inspector users. Now, we are happy to provide you with an update. Style Presentation Did you find yourself in a situation when you entered a big and complex gradient definition for yourbackground property, and it disappeared once you hit Return? The reason was that the Styles sidebar showed the style content exactly the way the browser understood it, and if it did not understand it, inspector showed nothing. This has now changed: inspector shows all the properties declared in a style, and if the browser does not understand a property name or value, the respective property is denoted by an exclamation mark ([image: warning]) next to its name. Still, you can edit (or remove) these properties along with the regular ones. On a related note, Web Inspector can now show the colors in property values exactly as they are written in the CSS – just use the “As Authored” presentation option accessible via the Gear menu. Editing Styles Based on the feedback from our users, we have improved the editing of CSS properties. Two separate fields are now used for a property name and value instead of one, and you can navigate between them (as well as between properties) back and forth with the Tab/Shift-Tab or Return keys. Available keywords for property values are suggested as you type, and can be auto-completed using the End or → keys, just like in the console view. The previous/next suggestions can be selected with the ↑ and ↓ keys. If you wish to accept the current suggestion and move on to another field, use the Tab/ Returnkeys. Additionally, you can paste a compound “name: value” property text into the name field, and inspector will break it up into “name” and “value”, putting each in its own field for you. Persisting Changes Every time you modify a style from an external style sheet, the respective resource text is updated in the Resources panel (this feature is work-in-progress) and the history is tracked for such style sheet resources while inspector remains open. Select any resource revision to see its differences from the original one, highlighted line-wise. A textual resource node (including stylesheet revisions) can be drag and dropped onto most text editors to export the specific resource content. Things You Might Not Know Please let us take this opportunity to tell a few things you might not know. While in the Styles pane, you can: - …add a new property to an editable style either by double-clicking in the blank space of the lines with opening and closing braces, or by hitting Tab while editing the last property value. - …add a new rule by selecting the “New Style Rule” item in the Gear menu. - …click a link in a property value (say, background-image) to navigate to the respective resource in the Resources panel. - …click a color swatch next to a color value to cycle through available color representation formats. We are currently experimenting with more improvements to style handling within Web Inspector. Stay tuned and check back often! On Wed, Feb 9, 2011 at 11:27 AM, Patrick Mueller pmue...@muellerware.org wrote: I'm logged in (as near as I can tell - link at the bottom says Log out), and still get the error. I don't have posting rights to the blog, nor do I want them. On 2/9/11 2:20 PM, Adele Peterson wrote: You have to be logged into the blog to read drafts. -- Patrick Mueller - http://muellerware.org ___ 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] Question regarding priorities of subresource content retrieval
On Mon, Feb 7, 2011 at 12:32 PM, Adam Barth aba...@webkit.org wrote: There is no PerformanceTest framework that deals with network latency. Please feel encouraged to build one. :) Note that http://code.google.com/p/web-page-replay/ was created with this goal (to simulate realistic network behavior). http://calendar.perfplanet.com/2010/benchmark-the-network/ has a few more details, and Tony Gentilcore (one of its authors) is on this list. Mihai ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Blog post(s) about layout tests
Hi Song, I've added a link to https://trac.webkit.org/wiki/WikiStart#LayoutTests at the end of the first post. Mihai On Tue, Jan 25, 2011 at 7:42 PM, song.7@nokia.com wrote: Hi, But where is the reference link in WebKit documentation site? A central place could help manage the doc and people find it… Thanks, Song *From:* webkit-dev-boun...@lists.webkit.org [mailto: webkit-dev-boun...@lists.webkit.org] *On Behalf Of *ext Mihai Parparita *Sent:* Wednesday, January 26, 2011 10:24 AM *To:* WebKit Development *Subject:* [webkit-dev] Blog post(s) about layout tests I noticed that we haven't done any posts on the WebKit blog about layout tests. Since getting good reductions in bug reports is very helpful, it seems like educating web developers about how we test things is helpful. I've written a draft pair of posts that talk about layout tests in general/theory (part I) and some nitty-gritty details that we run into with the system as it stands today (part II). The posts can also be combined into one, if that makes more sense: https://docs.google.com/document/pub?id=17OqoB-eBxcsJHpZeAyBAOUPG3Y903Ef2S-PKfKM4xBQ I've shown the draft to a few web developer friends, and their eyes didn't totally glaze over :). The post is link-heavy (generally into Trac, and Bugzilla), I'm hoping that would also encourage exploration of the code/site by people interested in contributing. Let me know if you think this is appropriate for the WebKit blog, and if so what the mechanics of posting on the blog are. Thanks, Mihai P.S. If you'd like to make comments on the document directly, let me know and I can add you as an editor. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] How to add a new file to mac build system?
You should also make sur that you're doing the same kind of build (i.e. debug vs. release) on both the command-line and in Xcode. Mihai On Tue, Jan 25, 2011 at 12:18 AM, Won J Jeon wjj...@gmail.com wrote: Thanks for your response. However, even though I changed the build directory to WebKit/WebKitBuild and added a custom executable (/Application/Safari.app), the same error occurred. BTW, I'm using XCode 3.2.5 on OS X 10.6.6. Won On Mon, Jan 24, 2011 at 11:38 PM, Ryosuke Niwa rn...@webkit.org wrote: Go to Project setting and set the build directory to be Project root/WebKitBuild. By default, it's at Source/WebCore/build and it won't just work. - Ryosuke On Mon, Jan 24, 2011 at 11:12 PM, Won J Jeon wjj...@gmail.com wrote: Thanks for your response. I have no problem to build WebKit from terminal by using 'build-webkit' script. When I open the project file, 'WebCore.xcodeproj' and tried to compile it by using the default settings, I have the endless error messages starting with: JavaScriptCore/Platform.h: No such file or directory PLATFORM is not defined Missing binary operator before token ( OS is not defined Missing binary operator before token ) PLATFORM is not defined Missing binary operator before token ( ... and it hangs. I have no problem to build 'JavaScriptCore.xcodeproj' with XCode though. Any suggestions? Thanks, Won On Mon, Jan 24, 2011 at 10:00 PM, Patrick Gansterer par...@paroga.comwrote: Please have a look at [1] and [2]. You need to run build-webkit first. BTW: If provide error messages instead of fails to compile only, it's easier for other people to help you. [1] http://webkit.org/building/build.html [2] http://webkit.org/building/debug.html - Patrick Won J Jeon: Thanks, Eric. I opened WebCore.xcodeproj file with XCode but it fails to compile the code and it hangs without success, whereas JavaScriptCore.xcodeproj doesn't have any problem to be compiled with XCode. Are there any known issues with XCode? Won On Mon, Jan 24, 2011 at 1:53 PM, Eric Seidel e...@webkit.org wrote: There is not a gyp-like build system for Apple's Mac build (yet). You generally need to use XCode to edit the WebCore.xcodeproj file. But if you're trying to build on a Mac you need XCode installed anyway. .pri and .pro are not related to the Apple Mac build. -eric On Mon, Jan 24, 2011 at 1:03 PM, Won J Jeon wjj...@gmail.com wrote: Hi all, I'd like to test some code by adding a new idl and its implementation to WebCore on Mac. How can I let the build system know the addition of such files? Is there any gyp-like build system on Mac? Can anyone explain what *.pri and *.pro files are and how I can use them? Regards, Won ___ 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 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] Blog post(s) about layout tests
I noticed that we haven't done any posts on the WebKit blog about layout tests. Since getting good reductions in bug reports is very helpful, it seems like educating web developers about how we test things is helpful. I've written a draft pair of posts that talk about layout tests in general/theory (part I) and some nitty-gritty details that we run into with the system as it stands today (part II). The posts can also be combined into one, if that makes more sense: https://docs.google.com/document/pub?id=17OqoB-eBxcsJHpZeAyBAOUPG3Y903Ef2S-PKfKM4xBQ I've shown the draft to a few web developer friends, and their eyes didn't totally glaze over :). The post is link-heavy (generally into Trac, and Bugzilla), I'm hoping that would also encourage exploration of the code/site by people interested in contributing. Let me know if you think this is appropriate for the WebKit blog, and if so what the mechanics of posting on the blog are. Thanks, Mihai P.S. If you'd like to make comments on the document directly, let me know and I can add you as an editor. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Best way to rebaseline 400+ tests?
The rebaseline server is checked in. https://trac.webkit.org/wiki/RebaselineServer has instructions on how to use it, please let me know if anything is unclear. Right now it only works well with local layout test results. I have a patch up at https://bugs.webkit.org/show_bug.cgi?id=52039 that makes it work with results from bots, but you still have to download the results (zip file) from the bot yourself. Next patch after that will hopefully do the downloading automatically. In either case, you first have to land your patch, have the tests fail (ideally, for bots that use NRWT you can pre-emptively add failing expectations to test_expectations.txt), and then rebaseline. There's still no easy to rebaseline ahead of time unless you have access to machines that can build the various affected ports. Coordinating with the (Chromium) gardener and other build cop-type people is helpful. Mihai On Fri, Jan 21, 2011 at 2:22 AM, Adam Barth aba...@webkit.org wrote: Unfortunately, we don't have a good solution to this problem at the moment. Mihai can comment on the status of webkit-patch rebaseline-server, which is pretty awesome. webkit-patch rebaseline is another option, but it's pretty bare-bones. Koz is working on a new rebaseline command to rule them all in https://bugs.webkit.org/show_bug.cgi?id=50098, but I'm not sure it's ready quite yet. His command will replace the exiting webkit-patch rebaseline command and possibly integrate with the rebaseline-server when its ready. Adam On Fri, Jan 21, 2011 at 1:21 AM, Yuzo Fujishima y...@google.com wrote: Hi, webkit-dev, I'm preparing a change (https://bugs.webkit.org/show_bug.cgi?id=41363) that will require rebaselining 400+ tests per platform. What is the best way to do the rebaselining? (My assumption is that the rebaselining tool is only for Chromium port). I can certainly handle my platform (Snow Leopard) by removing the existing expectations and having run-webkit-test generate new ones. But what should I do for other platforms? Yuzo ___ 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] Leopard Bot has been broken for 5 days.
If this is the same as http://webkit.org/b/51807, then it's actually been broken for a couple of weeks. Mihai On Tue, Jan 18, 2011 at 10:12 PM, Adam Barth aba...@webkit.org wrote: I investigated this issue for a while. Disabling the test just causes the next test to fail. I'm not very familiar with this code. I can spend more time investigating, but having someone familiar with ideographs would likely be more efficient. Adam On Tue, Jan 18, 2011 at 4:49 PM, Eric Seidel e...@webkit.org wrote: I ran webkit-patch failure-reason on Leopard Intel Release (Tests) and got: SUCCESS: Build 26596 (r75728) was the first to show failures: set([u'fast/blockflow/broken-ideograph-small-caps.html']) Suspect revisions: r75726: http://trac.webkit.org/changeset/75726 Bug: 52364 (https://bugs.webkit.org/show_bug.cgi?id=52364) Author: Csaba Osztrogonác o...@webkit.org Reviewer: Darin Adler da...@apple.com Committer: Csaba Osztrogonác o...@webkit.org r75727: http://trac.webkit.org/changeset/75727 Bug: None (None) Author: Tony Chang t...@chromium.org Reviewer: None Committer: Tony Chang t...@chromium.org r75728: http://trac.webkit.org/changeset/75728 Bug: 52317 (https://bugs.webkit.org/show_bug.cgi?id=52317) Author: Dimitri Glazkov dglaz...@chromium.org Reviewer: None Committer: Dimitri Glazkov dglaz...@chromium.org Explained all results for Leopard Intel Release (Tests) But those don't actually look related to the failure. I suspect the bot has a configuration issue. Could someone who has access to the bot give it a kick? -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 mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] New mailling list for buildbot events?
I'm not sure which category purple bots fall into, but getting notified about those would be useful (e.g. for the Chromium bots that Dimitri, James and I try to keep up). Mihai On Thu, Jan 13, 2011 at 7:29 PM, Eric Seidel e...@webkit.org wrote: Interesting. both warning and problem builds sound useful to be able to query via a mailing list archive. :) On Thu, Jan 13, 2011 at 7:21 PM, William Siegrist wsiegr...@apple.com wrote: On Jan 13, 2011, at 5:41 PM, Ryosuke Niwa wrote: On Thu, Jan 13, 2011 at 5:23 PM, William Siegrist wsiegr...@apple.com wrote: Some people have asked for a way to get email from build.webkit.org for build events/results. The simplest and easiest-to-maintain way I think to do this is to make a new mailing list and have the master use that for all buildbot notifications. People can subscribe and use mail filters to get what they really want. Admittedly, that list will get pretty noisy. Does anyone have any better ideas or objections? What kind of messages will be posted on such a mailing list? It is configurable and the choices are: * all Send mail about all builds, both passing and failing * change Only send mail about builds which change status * failing Only send mail about builds which fail * warning Only send mail about builds which fail or generate warnings * passing Only send mail about builds which succeed * problem Only send mail about a build which failed when the previous build has passed. -Bill ___ 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] Fixing Qt and Chromium builds
Looks like http://trac.webkit.org/changeset/74899 will fix things. Mihai On Mon, Jan 3, 2011 at 9:56 AM, Mihai Parparita mih...@chromium.org wrote: I'm Chromium gardener, and I'll take a look at the Chromium compile errors. Mihai On Mon, Jan 3, 2011 at 9:46 AM, Darin Adler da...@apple.com wrote: To fix Qt I need to add includes of ExceptionCode.h to two source files. To fox Chromium I have to figure out why my code change to not use defaultChecked seems to have been ineffective. I will be able to deal with these in an hour or so. If someone else can do so sooner that would be great. I hope it won't be necessary to roll the change out. -- Darin Sent from my iPhone ___ 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] Support for CSS3 gradients landed; ports will need minor changes
I've filed https://bugs.webkit.org/show_bug.cgi?id=51841 about making the change for Chromium/Skia. Mihai On Mon, Jan 3, 2011 at 11:45 AM, Simon Fraser simon.fra...@apple.com wrote: I just landed support for CSS3 gradients (see http://dev.w3.org/csswg/css3-images/#gradients), via https://bugs.webkit.org/show_bug.cgi?id=28152. The spec now allows elliptical gradients. Since some platforms may be able to render elliptical gradients natively, the code relies on the platform to render such gradients. In CG, this is done via a scale transform on the graphics context. Non-CG platforms will need to make changes to do something similar so what I do for CG: CGContextTranslateCTM(ctx, m_p0.x(), m_p0.y()); CGContextScaleCTM(ctx, 1, 1 / aspectRatio()); CGContextTranslateCTM(ctx, -m_p0.x(), -m_p0.y()); Please file a bug and fix your port accordingly. Thanks Simon ___ 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] Renaming directories
On Tue, Dec 21, 2010 at 6:12 PM, Ryosuke Niwa rn...@webkit.org wrote: Why don't we do this as we change the format of render tree dumps. We can remove expected tests from LayoutTests, move tests to RegressionTests with new expected results. I don't think an incremental migration will work well here, especially if it can't be easily automated (if it involves output format changes). We're going to have both directories for years, and people new to the project will be confused as to which tests to run, where to add new ones (if related ones haven't been migrated yet), etc. Mihai ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Snow Leopard Pixel Baselines
James Robinson and I* have been working on updating the pixel baselines in platform/mac so that they pass on Snow Leopard (we've been moving existing baselines to platform/mac-leopard so that things still work on Leopard too). Having up to date pixel baselines is helpful when making layout code changes, and for derivative ports that can use the mac baselines (e.g. chromium-mac). When we started there were more than 2,000 failing tests, mainly due to expected rendering differences in text anti-aliasing and colors (e.g. green is now actually #008000). With the help of some tools, we're now down to around 110 tests. The failures are more subtle, so it would be helpful to get people who know a bit more about is actually being tested to look at the results before updating them. http://bit.ly/sl-rebaselines has the list of failing tests and links for expected/actual/diffs (this requires a Google Account to view, and lets you edit the spreadsheet; http://bit.ly/sl-rebaselines-static is a static version that can be viewed when signed out too). If you'd like to help out, claim test(s) from the list above, and then update the checked in mac baselines (moving existing ones to mac-leopard). One thing that may be helpful is the rebaseline server tool that I wrote that lets you quickly go through image diffs and update baselines (and move existing ones to mac-leopard). https://trac.webkit.org/wiki/RebaselineServer explains how to use it. Let me know if something doesn't make sense or if you have any questions (I'm mihaip in #webkit). Thanks, Mihai * with a cameo appearance by Dave Hyatt ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Tip: Use 64-bit git binaries on Mac OS X
Update: The maintainer of the binaries http://code.google.com/p/git-osx-installer/ has agreed to provide both i386 and x86_64 installers now (and has uploaded builds of 1.7.3.3 with both), so hopefully it should be easier to get the latter now. Mihai On Thu, Dec 9, 2010 at 3:43 AM, Jeremy Orlow jor...@chromium.org wrote: For what it's worth, on my 12GB of ram mac pro: $ sudo sysctl -w kern.maxvnodes=384000 kern.maxvnodes: 197632 - 384000 Took times from 2.11-2.06 down to 2.05-2.02. I.e. it made a small difference, but not much. The 64 bit patch definitely seemed to help, but I didn't think to time before and after. J On Wed, Dec 8, 2010 at 11:38 PM, Eric Seidel e...@webkit.org wrote: Mark Rowe pointed out to me over IRC that the real problem is we're blowing out the vnode cache. Even on an 8GB machine, the default cache is too small for all of WebKit to fit in it. On my 4GB machine (and on Mark's 8GB) we tried incrementing the cache to 384000 (the 4GB default is 64512 and the 8GB default is 128000). My git status times dropped again by over 50% to 2.6 seconds! (still an eternity compared to a linux machine of course...) If you'd like to play around with this, you can set your vnode cache limit with: sudo sysctl -w kern.maxvnodes=384000 You can read it with: sysctl kern.maxvnodes You can test to see if the cache is large enough by trying: git status; time git status the second one should be very fast if your cache is large enough. I don't know what the exact right trade-off is. I believe the vnode cache uses wired memory (which is a limited resource!). As far as I can tell you can't decrease the cache max w/o rebooting. sysctl will set it, but setting it to a smaller number seems to have not effect. I don't know how to make the setting last across reboots. Mark mentioned that putting the setting in /etc/sysctl.conf should work, but that at least for his machine that didn't seem to have any effect for this particular setting. That's what I know. -eric On Wed, Dec 8, 2010 at 3:02 PM, Eric Seidel e...@webkit.org wrote: FYI, my git status runs on my Mac Book Pro were an average of 9.2 seconds (git version 1.7.1, git-osx-installer) before installing Mihai's 64bit build (git version 1.7.3.3), and were 6.0 seconds after. -eric On Wed, Dec 8, 2010 at 2:20 PM, Eric Seidel e...@webkit.org wrote: I've posted a patch to make webkit-patch warn users when they're on a 64-bit system with a 32-bit git: https://bugs.webkit.org/show_bug.cgi?id=50715 4 seconds on every git status is huge. webkit-patch upload has to run at least 3 git status commands (due to expecting files to change on disk during operation), so this means a savings of 12 seconds on your machine! -eric On Tue, Dec 7, 2010 at 4:04 PM, Mihai Parparita mih...@chromium.org wrote: After complaining to a Linux-using friend for the n-th time that git status was much slower on my Snow Leopard machine than on his Linux box, I decided to look into why this is. As it turns out, most people get git binaries from http://code.google.com/p/git-osx-installer/, which are 32-bit. Switching to 64-bit binaries made git status go from 6.58s to 2.50s (mainly because this does fewer mmaps). You can download a 64-bit binary installer from https://github.com/downloads/mihaip/git_osx_installer/git-1.7.3.3-intel-x86_64-leopard.dmg , or you can build it yourself (more details at http://blog.persistent.info/2010/12/making-git-faster-on-large-repositories.html ). 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Tip: Use 64-bit git binaries on Mac OS X
Thanks for the reminder about NO_MMAP. I just tried it out, and things appeared to be slower with it, so it doesn't seem to be a good idea. I'll contact the maintainer about providing fat 32/64-bit binaries by default. The resulting .dmg is 8.5MB (vs. 4.5MB for the i386-only one), so I think the bloat concerns are minimal. Mihai On Tue, Dec 7, 2010 at 4:26 PM, Evan Martin e...@chromium.org wrote: It seems from the bug Mihai linked to that the Git+OS X maintainer thought the only benefit of a 64-bit binary was being able to handle larger files, but in fact the real benefit is that the increased address space of a 64-bit binary lets you mmap larger regions. So it seems reasonable you could convince the maintainer. But really, large mmap regions is mostly working around the fact that Mihai was experiencing mmap taking 40ms. Git Master Shawn Pearce said to me: Try compiling Git with make NO_MMAP=1 and tell me how you like it. Git comes with a replacement mmap() implementation that does malloc()+read(). This was primarily meant for Win32 cases, but might be useful on Mac OS X. In the old thread on the Git list about OS X performance that Mihai linked to in his blog post, Linus Torvalds seemed to indicate that he only expected mmap to have performance comparable to read on Linux, not on other platforms. So I'd maybe suggest trying that as well and then telling the Git+OS X maintainer which combination of settings is the best. :) On Tue, Dec 7, 2010 at 4:14 PM, Eric Seidel e...@webkit.org wrote: Can we evangelize the code.google.com project? On Dec 7, 2010 4:04 PM, Mihai Parparita mih...@chromium.org wrote: After complaining to a Linux-using friend for the n-th time that git status was much slower on my Snow Leopard machine than on his Linux box, I decided to look into why this is. As it turns out, most people get git binaries from http://code.google.com/p/git-osx-installer/, which are 32-bit. Switching to 64-bit binaries made git status go from 6.58s to 2.50s (mainly because this does fewer mmaps). You can download a 64-bit binary installer from https://github.com/downloads/mihaip/git_osx_installer/git-1.7.3.3-intel-x86_64-leopard.dmg, or you can build it yourself (more details at http://blog.persistent.info/2010/12/making-git-faster-on-large-repositories.html). 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Rebaselining render tree dumps
On Mon, Dec 6, 2010 at 12:30 PM, David Hyatt hy...@apple.com wrote: What do people think of this idea? How can we make sure that a rebaselining like this goes smoothly? I think this is a great idea. As far as how to do this, prompted by the Leopard - Snow Leopard switch (which is causing lots of pixel baselines to be updated), I've been working on a tool to make it easier to do such mass rebaselines. I've documented it here: https://trac.webkit.org/wiki/RebaselineServer. It seems that something like this (that perhaps shows image output even if there were no image diffs, to help understand the text version of the render tree) could help. For organizing, it seems like diving things up by directory with a wiki/spreadsheet where people can claim a directory to update might be an option? Mihai ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Trouble running new-run-webkit-tests
A workaround until this is fixed is to pass --release (or --debug as appropriate) to NRWT. Mihai On Fri, Nov 19, 2010 at 7:47 AM, W. James MacLean wjmacl...@chromium.org wrote: I'm trying to generate baselines for a new test, using the command WebKitTools/Scripts/new-run-webkit-tests --new-baseline test I have previously done (successfully) WebKitTools/Scripts/build-webkit WebKitTools/Scripts/build-dumprendertree When I try to run the new-run-webkit-tests, it tells me that it cannot find DumpRenderTree. It was looking in WebKitBuild/ instead of WebKitBuild/Release where the executables actually were. After copying both DumpRenderTree and ImageDiff up from the Release directory, I now get a failed test because DumpRenderTree crashed, and the stack trace is full of messages like DumpRenderTree[44776:903] Failed to activate fonts: blah ... blah ... I am using the wrong work flow? Why is the build script putting executables in one place wile new-run-webkit-tests is looking for them in another place? James ___ 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] Pixel output for text/plain responses in layout tests
I've been working on updating pixel baselines for Snow Leopard, and ran into a test that fails due to missing pixel baselines (http/tests/incremental/slow-utf8-text.pl) and was surprised how we ever passed this test. As it turns out, this test just outputs a text/plain response, which is special-cased by the various DRT implementations to simulate LayoutTestController.dumpAsText being called. However, for the Chromium port (which are the only ones to actually enable pixel tests as far as I know), a text/plain content type turns off pixel output in addition to turning on text output: http://trac.webkit.org/browser/trunk/WebKitTools/DumpRenderTree/chromium/TestShell.cpp#L435 While for other ports, it just enables text output, but leaves pixel output alone (i.e. enabled if -p was passed to run-webkit-tests): http://trac.webkit.org/browser/trunk/WebKitTools/DumpRenderTree/mac/DumpRenderTree.mm#L916 http://trac.webkit.org/browser/trunk/WebKitTools/DumpRenderTree/gtk/DumpRenderTree.cpp#L505 http://trac.webkit.org/browser/trunk/WebKitTools/DumpRenderTree/win/DumpRenderTree.cpp#L675 I have a slight preference for the Chromium behavior (pixel baselines are brittle/annoying to maintain, if the output is text then layout is not relevant/interesting), but either way consistency between ports is best. Does anyone have any opinions about this? Mihai ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Pixel output for text/plain responses in layout tests
On Fri, Nov 19, 2010 at 11:19 AM, David Levin le...@chromium.org wrote: Would you figure out which tests would be affected by this change? And then reply with that list of tests. As best as I can tell, the test that I originally mentioned (http/tests/incremental/slow-utf8-text.pl) is the only one that's affected: https://www.google.com/codesearch?hl=envert=chromiumlr=q=file:third_party/webkit/layouttests+text/plain+-file:resources+file:(pl|php)$sbtn=Search That test is also the only mentioned in other places that talk about special-casing text/plain output: https://bugs.webkit.org/show_bug.cgi?id=44282 http://trac.webkit.org/browser/trunk/LayoutTests/platform/mac-wk2/Skipped#L1824 Mihai ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] pixel tests and --tolerance (was Re: Pixel test experiment)
FWIW, I needed NRWT to support --tolerance for something else today (mainly because when using it with the Mac port, it defaults to 0.1 tolerance, with no way to override it), so I added NRWT support for it: http://webkit.org/b/47959. Mihai On Thu, Oct 14, 2010 at 2:44 PM, Dirk Pranke dpra...@chromium.org wrote: On Thu, Oct 14, 2010 at 9:06 AM, Ojan Vafai o...@chromium.org wrote: Dirk, implementing --tolerance in NRWT isn't that hard is it? Getting rid of --tolerance will be a lot of work of making sure all the pixel results that currently pass also pass with --tolerance=0. While I would support someone doing that work, I don't think we should block moving to NRWT on it. Assuming we implement it only for the ports that currently use tolerance on old-run-webkit-tests, no, I wouldn't expect it to be hard. Dunno how much work it would be to implement tolerance on the chromium image_diff implementations (side note: it would be nice if these binaries weren't port-specific, but that's another topic). As to how many files we'd have to rebaseline for the base ports, I don't know how many there are compared to how many fail pixel tests, period. I'll run a couple tests and find out. -- Dirk Ojan On Fri, Oct 8, 2010 at 1:03 PM, Simon Fraser simon.fra...@apple.com wrote: I think the best solution to this pixel matching problem is ref tests. How practical would it be to use ref tests for SVG? Simon On Oct 8, 2010, at 12:43 PM, Dirk Pranke wrote: Jeremy is correct; the Chromium port has seen real regressions that virtually no concept of a fuzzy match that I can imagine would've caught. new-run-webkit-tests doesn't currently support the tolerance concept at al, and I am inclined to argue that it shouldn't. However, I frequently am wrong about things, so it's quite possible that there are good arguments for supporting it that I'm not aware of. I'm not particularly interested in working on a tool that doesn't do what the group wants it to do, and I would like all of the other WebKit ports to be running pixel tests by default (and new-run-webkit-tests ;) ) since I think it catches bugs. As far as I know, the general sentiment on the list has been that we should be running pixel tests by default, and the reason that we aren't is largely due to the work involved in getting them back up to date and keeping them up to date. I'm sure that fuzzy matching reduces the work load, especially for the sort of mismatches caused by differences in the text antialiasing. In addition, I have heard concerns that we'd like to keep fuzzy matching because people might potentially get different results on machines with different hardware configurations, but I don't know that we have any confirmed cases of that (except for arguably the case of different code paths for gpu-accelerated rendering vs. unaccelerated rendering). If we made it easier to maintain the baselines (improved tooling like the chromium's rebaselining tool, add reftest support, etc.) are there still compelling reasons for supporting --tolerance -based testing as opposed to exact matching? -- Dirk On Fri, Oct 8, 2010 at 11:14 AM, Jeremy Orlow jor...@chromium.org wrote: I'm not an expert on Pixel tests, but my understanding is that in Chromium (where we've always run with tolerance 0) we've seen real regressions that would have slipped by with something like tolerance 0.1. When you have 0 tolerance, it is more maintenance work, but if we can avoid regressions, it seems worth it. J On Fri, Oct 8, 2010 at 10:58 AM, Nikolas Zimmermann zimmerm...@physik.rwth-aachen.de wrote: Am 08.10.2010 um 19:53 schrieb Maciej Stachowiak: On Oct 8, 2010, at 12:46 AM, Nikolas Zimmermann wrote: Am 08.10.2010 um 00:44 schrieb Maciej Stachowiak: On Oct 7, 2010, at 6:34 AM, Nikolas Zimmermann wrote: Good evening webkit folks, I've finished landing svg/ pixel test baselines, which pass with --tolerance 0 on my 10.5 10.6 machines. As the pixel testing is very important for the SVG tests, I'd like to run them on the bots, experimentally, so we can catch regressions easily. Maybe someone with direct access to the leopard snow leopard bots, could just run run-webkit-tests --tolerance 0 -p svg and mail me the results? If it passes, we could maybe run the pixel tests for the svg/ subdirectory on these bots? Running pixel tests would be great, but can we really expect the results to be stable cross-platform with tolerance 0? Perhaps we should start with a higher tolerance level. Sure, we could do that. But I'd really like to get a feeling, for what's problematic first. If we see 95% of the SVG tests pass with --tolerance 0, and only a few need higher tolerances (64bit vs. 32bit aa differences, etc.), I could come up with a per-file pixel test tolerance extension to DRT, if it's needed. How about
Re: [webkit-dev] Throwing SECURITY_ERR on cross-origin window.location property accesses
Just to clarify, I'm only looking to add exception throwing to cross-origin property accesses of the location object, not for the whole window object. As for real-world uses of location.href throwing an exception, a new comment just got added to: http://code.google.com/p/chromium/issues/detail?id=17325#c16 Comment 16 by r...@electronicinsight.com, Today (4 minutes ago) There is definitely real-world use case for this for WebKit. At Sprout (http://sproutinc.com) we have a generic platform to design mobile HTML5 ads. We allow designers to link elements in top window and new window. If they choose top window, in Android 2.2 the top window link will just refresh the current page when doing window.top.location.href = url. We need a way to test for the security exception and then do window.open(url) instead when that security error is trapped. Mihai On Tue, Aug 17, 2010 at 3:28 PM, Adam Barth aba...@webkit.org wrote: On Mon, Aug 16, 2010 at 7:49 PM, Maciej Stachowiak m...@apple.com wrote: On Aug 13, 2010, at 9:59 AM, Mihai Parparita wrote: On Fri, Aug 13, 2010 at 12:42 AM, Maciej Stachowiak m...@apple.com wrote: 1) It means the access control goes in fewer places - we don't have to have access control on every document property, only window properties. I'm not quite sure I understand this. At least for the location object, I see an explicit check in JSLocationCustom.cpp: http://trac.webkit.org/browser/trunk/WebCore/bindings/js/JSLocationCustom.cpp#L71. Throwing the exception would happen there too (it won't require custom getters for each property). Yes, a small handful of objects that hang off of Window are accessible cross-origin and have their own security checks. However, one property of Window is handled very differently between WebKit-based browsers and what the spec calls for. someCrossOriginWindow.document returns undefined in WebKit-based browsers, but it returns a document object per the spec which then does its own security check on every property access. This is unfortunate because the attack surface is increased and performance suffers. And it's not Web-compatible to just throw on access to the document property - Web apps expect they can always ask for the document, and it's the *next* property access that throws, which is fulfilled by returning undefined since accessing a property of the undefined value throws in JS. For cases like the location object, it doesn't matter much either way. I believe the spec no longer exposes someCrossOriginWindow.document. (As to whether it throws a security exception or returns null, I'd have to look more carefully.) Adam ___ 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
I was wondering if there are any other thoughts on this. It seems like there's real-world need from this (based on the usages I tracked down, and log spam problem) and all other browsers (and the HTML5 spec) have the exception-throwing behavior. Thanks, Mihai On Fri, Aug 13, 2010 at 10:19 AM, Mihai Parparita mih...@chromium.orgwrote: On Fri, Aug 13, 2010 at 9:59 AM, Mihai Parparita mih...@chromium.org wrote: I've asked Joseph (the original reporter of http://crbug.com/17325) where he ran into this. Joseph replied and said While there is a proprietary web app that relies on this, but it is used at a small company I no longer work for and have no access to. However, I do remember it being a little frustrating developing around this since Firefox and IE both throw the exception. The other reason why throwing the exception might be preferable is to avoid console log spam. For example, http://www.nytimes.com/ has lots of iframes that (for whatever reason) reach into the parent (or vice-versa). In Safari and Chrome, the console has 6 unsafe JavaScript access messages, which the developer can't avoid, even if they're expecting possible errors (in Firefox there's only 1, so I assume at least some of their JS has try/catch blocks around cross-origin access). If we replace the printErrorMessageForFrame call with setDOMException(exec, SECURITY_ERR) then developers who catch the exception can avoid the log message. 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
On Fri, Aug 13, 2010 at 12:42 AM, Maciej Stachowiak m...@apple.com wrote:
1) It means the access control goes in fewer places - we don't have to have
access control on every document property, only window properties.
I'm not quite sure I understand this. At least for the location
object, I see an explicit check in JSLocationCustom.cpp:
http://trac.webkit.org/browser/trunk/WebCore/bindings/js/JSLocationCustom.cpp#L71.
Throwing the exception would happen there too (it won't require custom
getters for each property).
So in general I'm not in a rush to change this. However, if the original bug
involved a compatibility problem on a real site (it doesn't really say),
then maybe that would be a stronger reason to change.
I've asked Joseph (the original reporter of http://crbug.com/17325)
where he ran into this. However, in the meantime, a quick code search
shows this pattern elsewhere too. For example, Dojo has this snippet
(in http://svn.dojotoolkit.org/src/dojo/trunk/hash.js):
try{
//see if we can access the iframe's location without a permission denied error
var iframeSearch = _getSegment(iframeLoc.href, ?);
//good, the iframe is same origin (no thrown exception)
And FCKEditor (a WYSIWYG editor) has this at
http://dev.ckeditor.com/browser/FCKeditor/trunk/fckeditor.js#L167:
try
{
if ( (/fcksource=true/i).test( window.top.location.search ) )
sFile = 'fckeditor.original.html' ;
}
catch (e) { /* Ignore it. Much probably we are inside a FRAME where
the top is in another domain (security error). */ }
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
On Fri, Aug 13, 2010 at 9:59 AM, Mihai Parparita mih...@chromium.org wrote: I've asked Joseph (the original reporter of http://crbug.com/17325) where he ran into this. Joseph replied and said While there is a proprietary web app that relies on this, but it is used at a small company I no longer work for and have no access to. However, I do remember it being a little frustrating developing around this since Firefox and IE both throw the exception. The other reason why throwing the exception might be preferable is to avoid console log spam. For example, http://www.nytimes.com/ has lots of iframes that (for whatever reason) reach into the parent (or vice-versa). In Safari and Chrome, the console has 6 unsafe JavaScript access messages, which the developer can't avoid, even if they're expecting possible errors (in Firefox there's only 1, so I assume at least some of their JS has try/catch blocks around cross-origin access). If we replace the printErrorMessageForFrame call with setDOMException(exec, SECURITY_ERR) then developers who catch the exception can avoid the log message. Mihai ___ 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] Why are we running Sputnik?
Nope, it's from Chromium: http://blog.chromium.org/2009/06/launching-sputnik-into-orbit.html http://blog.chromium.org/2010/03/does-your-browser-behave.html Mihai On Tue, Aug 10, 2010 at 1:30 PM, Dirk Pranke dpra...@chromium.org wrote: I thought Sputnik came from Microsoft? -- Dirk On Tue, Aug 10, 2010 at 11:51 AM, Eric Seidel e...@webkit.org wrote: Chromium skips it (and if I remember correctly, they commissioned it?) Why do we want to be running these 6000 tests and slowing down our builds. I was talking with jamesr, and he seemed to think it adds little value to run it every time? (It was supposedly written as more of a development tool for V8?) But maybe I'm missing something? -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 mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
