Re: [webkit-dev] build.webkit.org down
On Fri, Jan 25, 2013 at 9:30 AM, William Siegrist wsiegr...@apple.comwrote: Here are the largest results sets on the master in GB. We currently store 6.8TB of total results, going back 14 months, and 1.1TB of archives going back 1 week. 1500Apple MountainLion (Leaks) 1018Chromium Mac Release (Tests) 857 Chromium Linux Release (Tests) 532 Chromium Win Release (Tests) 371 Apple MountainLion Debug WK2 (Tests) 324 Apple Lion Debug WK2 (Tests) 299 Chromium Linux Release (Grid Layout) The Grid Layout bot no longer exists. We can delete these archived results. tony ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Commit queue stopped working
If Chromium DRT crashes, it will leak temp files. Maybe run-webkit-tests should try to clean these up? On Thu, Jan 24, 2013 at 10:15 AM, Adam Barth aba...@webkit.org wrote: Thanks for the note. We seem to have a temp file leak in run-webkit-tests. I'm rebuilding the machines now. Adam On Thu, Jan 24, 2013 at 10:03 AM, Dumez, Christophe christophe.du...@intel.com wrote: Hi, It appears the commit queue stopped working due to lack of disk space: https://bugs.webkit.org/show_bug.cgi?id=107680#c8 Failed to run ['/mnt/git/webkit-commit-queue/Tools/Scripts/webkit-patch', '--status-host=queues.webkit.org', '--bot-id=gce-cq-04', 'apply-attachment', '--no-update', '--non-interactive', 184451, '--port=chromium-xvfb'] exit_code: 2 cwd: /mnt/git/webkit-commit-queue Last 500 characters of output: -queue Parsed 4 diffs from patch file(s). patch: Can't create file /tmp/pptQe127 : No space left on device patch: Can't create file /tmp/ppIK0MM8 : No space left on device patch: Can't create file /tmp/ppTdTd08 : No space left on device patch: Can't create file /tmp/pp8tZQ8b : No space left on device Kr, -- Christophe Dumez, PhD Linux Software Engineer Intel Finland Oy - Open Source Technology Center ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] generic test expectations?
On Tue, Nov 13, 2012 at 11:35 AM, Dirk Pranke dpra...@chromium.org wrote: On Tue, Nov 13, 2012 at 11:29 AM, Glenn Adams gl...@skynav.com wrote: On Tue, Nov 13, 2012 at 12:09 PM, Dirk Pranke dpra...@chromium.org wrote: We don't currently support port-specific reftests (or at least, not very well), and we certainly should be trying to minimize where they occur. Hmm, I actually used port specific reftest expectation files in a recent patch [1] (since rolled out), and it appeared to work (as a way to effectively rebaseline those expectations). So something seems to be working. [1] http://trac.webkit.org/changeset/133529 I expect it'll sort of work, but it won't be robust; you may hit weird behavior and/or bugs. We really haven't beaten on this aspect of things, and I don't know yet how much we want to. I don't think we should support port specific ref test results. That kind of misses the point of using a ref test in the first place. I mean, you may as well check in port specific pixel results which are easier to review for correctness. It may be the case that a ref test is not appropriate for what you're trying to test. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] generic test expectations?
On Tue, Nov 13, 2012 at 12:04 PM, Darin Adler da...@apple.com wrote: On Nov 13, 2012, at 12:02 PM, Tony Chang t...@chromium.org wrote: I don't think we should support port specific ref test results. That kind of misses the point of using a ref test in the first place. I mean, you may as well check in port specific pixel results which are easier to review for correctness. I don’t agree that pixel results are easier to review for correctness. Here is a ref test result from ietestcenter: http://trac.webkit.org/browser/trunk/LayoutTests/ietestcenter/css3/flexbox/flexbox-flex-002-expected.htm Looking at that HTML file, it's not immediately obvious that the result is correct. If I had a png file, it would easy to see if there's red showing or not. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Settings and Preferences in layout tests
On Wed, Sep 26, 2012 at 2:35 PM, Brady Eidson beid...@apple.com wrote: On Sep 26, 2012, at 2:05 PM, Adam Barth aba...@webkit.org wrote: [re-sent from the proper address] On Wed, Sep 26, 2012 at 2:00 PM, Adam Barth abarth@nowhere wrote: On Wed, Sep 26, 2012 at 1:53 PM, Brady Eidson beid...@apple.com wrote: On Sep 26, 2012, at 1:48 PM, Ryosuke Niwa rn...@webkit.org wrote: On Wed, Sep 26, 2012 at 1:44 PM, Simon Fraser simon.fra...@apple.comwrote: First, direct calls on testRunner that just set preferences should be migrated to internals.settings or testRunner.overridePreference calls, I think (I don't know if either is preferred). I support the idea of unifying the approaches and just use internals.settings. However, the last time I checked, Alexey had some concerns about using internals due to settings may not be properly propagated to WebKit2 layer. Has this concern been addressed? In general I prefer the overridePreference() calls whenever they exist. internals.settings are not exposed in any real-world product whereas preferences exist in each platform's WebKit-layer API that they expose to their embedders in some form. The main downside of overridePreference is that it requires that you expose an API for twiddling the preference on every port. That can lead to us exposing unneeded APIs (making them harder to remove) and to a bunch of port-specific code in an otherwise port-independent patch. IMHO, we should prefer InternalSettings unless we need to test the WebKit-layer code. I suppose we're biased in Mac-land where the mechanism originated, but the API is simply a single string based API that only had to be implemented once. Your comment leads me to understand that at least one other port doesn't have simple string based preferences. Of course to add *any* new internal setting new code must be added specifically for that setting... Of course that code only has to be added once for all platforms… I think for all the major ports, they are simple string based preferences. However, adding a new overridePreference call means updating 5 WebKit API interfaces (Mac, Win, Chromium, GTK+, QT), and updating 5 DRTs and 1 WTR. Compared to updating a single internal.settings implementation, this is a lot of work. In addition to being a lot of work, it increases the size of each WebKit API even if the particular port doesn't want/need to expose the feature. tony ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Easing printf based debugging in WebKit with an helper.
On Thu, Jul 19, 2012 at 11:35 AM, Oliver Buchtala oliver.bucht...@googlemail.com wrote: On 19.07.2012 20:26, Maciej Stachowiak wrote: On Jul 19, 2012, at 11:01 AM, Oliver Buchtala oliver.buchtala@googlemail.**com oliver.bucht...@googlemail.com wrote: FWIW, there is a gdb python API for changing the behavior... so called pretty printers. It is not too difficult to write such pretty-printers. Maybe providing a set of useful pretty-printers is a better approach than providing a set of debug functions? I would love to see a set of useful pretty printers that we could share. Do you have any we could use as a starting point? I have written some for other projects... not yet for webkit. Brady noted that there are some of them around? I could provide some pretty-printers, if necessary... There are some already in WebKit/Tools/gdb/webkit.py. It already includes formatters for WTF::String, WTF::CString and more. Feel free to add more to it. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] How to specify the window size in DumpRenderTree?
In your test case, you should be able to use window.resizeTo to change the size of the window. On Fri, Feb 24, 2012 at 5:01 AM, Mayur K emineme...@gmail.com wrote: Hi, I want to specify the window size/view size in DumpRenderTree, so that rendertree, can reflect the structure according to the new window size. Is there an existing option/method to do so? Thanks in advance. --Mayur Kankanwadi. -- Symbiangeek,Codekata Webkitwiki all in one - http://flaminghorns.com ___ 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] Style bot complains of missing binary data in diff when deleting .png test results
The change you suggest for VCSUtils.pm seems fine to me, but if you use 'webkit-patch upload', it'll generate a diff that svn-apply can successfully apply. On Wed, Nov 30, 2011 at 5:42 PM, Alan Stearns stea...@adobe.com wrote: David, This is a bug where I accidentally turned on a pixel result, then needed to remove the .pngs when I fixed the problem: https://bugs.webkit.org/show_bug.cgi?id=73343 The patch had two lines like this: Binary files a/LayoutTests/platform/efl/fast/regions/no-split-line-box-expected.png and /dev/null differ Which resulted in this output from style-queue: Failed to run [u'/mnt/git/webkit-style-queue/Tools/Scripts/svn-apply', u'--force'] exit_code: 9 Error: the Git diff contains a binary file without the binary data in line: Binary files a/LayoutTests/platform/efl/fast/regions/no-split-line-box-expected.png and /dev/null differ. Be sure to use the --binary flag when invoking git diff with diffs containing binary files. at /mnt/git/webkit-style-queue/Tools/Scripts/VCSUtils.pm line 667, ARGV line 45. Thanks, Alan On 11/30/11 5:36 PM, David Levin le...@chromium.org wrote: Perhaps you could give a bug that has an example of what you are talking about. For me it is hard to guess at what the complaint by the style bot is. dave On Wed, Nov 30, 2011 at 5:20 PM, Alan Stearns stea...@adobe.com wrote: If I delete a .png test result and I make a git diff without using the --binary flag, the style EWS bot complains. I can see why it would complain if I were rebasing the file - you need the binary data to see what's changed. It makes less sense to me to add the binary data to the diff if the file is just being deleted. Should VCSUtils.pm detect a ... and /dev/null differ line and let it through? Are there dependencies on the binary data in svn-apply or other tools? I'm planning on replacing some pixel-based verification with reftests in the near future, and so I'll be deleting quite a few .png files. I don't mind slinging around all that binary data, but if it's not really needed I'd rather leave it out. Thanks, Alan ___ 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] Removing Support for Python 2.5
The bot step that runs ui_tests uses scripts/slave/runtest.py. You could probably set PATH in that script before launching ui_tests. http://build.chromium.org/p/chromium/builders/Mac10.5%20Tests%20%282%29/builds/10395/steps/ui_tests/logs/stdio http://src.chromium.org/viewvc/chrome/trunk/tools/build/scripts/slave/runtest.py?revision=103047view=markup On Thu, Nov 17, 2011 at 5:22 PM, Adam Barth aba...@webkit.org wrote: (Sorry if we're spamming webkit-dev with this thread. We can move it to a Chromium infrastructure mailing list if we're bugging anyone.) On Thu, Nov 17, 2011 at 5:17 PM, Dirk Pranke dpra...@chromium.org wrote: On Thu, Nov 17, 2011 at 5:06 PM, Eric Seidel e...@webkit.org wrote: On Thu, Nov 17, 2011 at 4:53 PM, Tony Chang t...@chromium.org wrote: new-run-webkit-httpd imports common/host.py which imports lots of stuff including common/net/buildbot.py, which will fail to import the json module. I would land smaller pieces so the rollback isn't as painful. :) Adam appears to have listed the files: http://codesearch.google.com/#search/exact_package=chromiumq=new-run-webkittype=cs Can someone with chromium commit-bit, please move those 3 files to call python 2.7 in whatever the proper way is, so we can move forward here? 2.7? Aren't we just requiring 2.6? I don't think any of the Chromium bots can assume 2.7 (except for the ones Tony has upgraded), and none of my machines (except for maybe my Lion machine at home) even have 2.7 installed. The pattern Tony used for new-run-webkit-tests was to detect whether Python 2.7 was installed at a certain path before trying to use it. That pattern seems like it would work in these cases too. The one tricky one is ui_test because the launcher is in C++. Perhaps it should call a wrapper script instead? Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Removing Support for Python 2.5
Only new-run-webkit-tests uses python 2.7 on the leopard bots. There are other bot steps in chromium that would break. I mention a couple cases here: http://code.google.com/p/chromium/issues/detail?id=103266#c6 Alternately, we could try to fully switch the leopard bots to 2.7 ( http://crbug.com/103828), but that's a larger task. On Thu, Nov 17, 2011 at 3:19 PM, Dirk Pranke dpra...@chromium.org wrote: On Thu, Nov 17, 2011 at 2:45 PM, Adam Barth aba...@webkit.org wrote: On Thu, Nov 17, 2011 at 2:42 PM, Dirk Pranke dpra...@chromium.org wrote: The Chromium Leopard bots are still using 2.5 as far as I know. Unless move forward includes you upgrading those bots, you shouldn't remove the 2.5 compat code until they have been upgraded. (If you are signing up to upgrade them, then great!). Tony already upgraded the bots. Adam I have been corrected. You have my blessings :). ___ 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] Removing Support for Python 2.5
new-run-webkit-httpd imports common/host.py which imports lots of stuff including common/net/buildbot.py, which will fail to import the json module. I would land smaller pieces so the rollback isn't as painful. :) On Thu, Nov 17, 2011 at 4:42 PM, Adam Barth aba...@webkit.org wrote: The remaining things seem related to websocket-server and new-run-webkit-httpd, which I don't think will be effected by your change. Adam On Thu, Nov 17, 2011 at 4:40 PM, Eric Seidel e...@webkit.org wrote: Other bot steps in Chromium depend on webkitpy? I'm tempted to just make the change and see what breaks. We can always roll it out if things are really bad. I'll prepare an updated patch. -eric On Thu, Nov 17, 2011 at 4:37 PM, Tony Chang t...@chromium.org wrote: Only new-run-webkit-tests uses python 2.7 on the leopard bots. There are other bot steps in chromium that would break. I mention a couple cases here: http://code.google.com/p/chromium/issues/detail?id=103266#c6 Alternately, we could try to fully switch the leopard bots to 2.7 (http://crbug.com/103828), but that's a larger task. On Thu, Nov 17, 2011 at 3:19 PM, Dirk Pranke dpra...@chromium.org wrote: On Thu, Nov 17, 2011 at 2:45 PM, Adam Barth aba...@webkit.org wrote: On Thu, Nov 17, 2011 at 2:42 PM, Dirk Pranke dpra...@chromium.org wrote: The Chromium Leopard bots are still using 2.5 as far as I know. Unless move forward includes you upgrading those bots, you shouldn't remove the 2.5 compat code until they have been upgraded. (If you are signing up to upgrade them, then great!). Tony already upgraded the bots. Adam I have been corrected. You have my blessings :). ___ 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
Re: [webkit-dev] Removing Support for Python 2.5
Are you sure? This output has references to System/Library/Frameworks/Python.framework/Versions/2.5. I also thought that's why NRWT was slow on the Leopard bots: python 2.5 doesn't have the multiprocess module. http://build.chromium.org/p/chromium.webkit/builders/Webkit%20Mac10.5%20%28dbg%29%281%29/builds/4090/steps/webkit_tests/logs/stdio It may just be a bug that these bots aren't using python2.6. On Fri, Nov 4, 2011 at 3:40 PM, Adam Barth aba...@webkit.org wrote: Yes, Chromium versions its Python independently from the OS. Adam On Fri, Nov 4, 2011 at 3:25 PM, Ojan Vafai o...@chromium.org wrote: I believe the chromium port always uses 2.6 though, no? On Fri, Nov 4, 2011 at 3:23 PM, Nico Weber tha...@chromium.org wrote: The chromium port still has a bot that runs tests (but doesn't build) on 10.5. Nico On Fri, Nov 4, 2011 at 3:20 PM, Eric Seidel e...@webkit.org wrote: Now that Apple has removed the Leopard build bot (and presumably stopped supporting WebKit on Leopard), all webkit platforms I know of have Python 2.6 or higher. My plan is to remove all of our 2.5 supporting code in the next week, requiring Python 2.6 or later for WebKit. Let me know if this will be an issue for you. Thanks! -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 ___ 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] Best practices for failing a flaky tests (was Re: Switching to new-run-webkit-tests)
One difference with the chromium port is that we try to use a single test_expectations.txt that covers all platforms and OS versions (win xp, vista, 7, mac leopard, snow leopard, linux 32, 64, GPU vs CPU, Debug vs Release). The tokens to the left of the test name specify what configuration the expectation applies to. Because of that, there hasn't been much need for multiple test_expectations.txt files. There is some code already in NRWT for cascading test_expectations.txt. Currently, it's specific to the chromium port where we merge the test_expectations.txt in the webkit repo with a test_expectations.txt file in the chromium repo (it just concatenates them together). It would be pretty straight forward to make this code generic for all ports. It seems like we have a few options. We could have a separate test_expectations.txt per layout test platform directory and have cascade logic hard coded into NRWT or with an #include directive. At the other extreme, we could have a single monolithic test_expectations.txt file that knows about all platforms. Or something in the middle: have a test_expectations.txt for mac, mac-leopard, mac-snowleopard, one for qt*, one for all the WebKit2 ports, etc. I suspect we'll want to go with something in the middle. On Thu, Jul 7, 2011 at 10:06 AM, Maciej Stachowiak m...@apple.com wrote: On Jul 7, 2011, at 10:03 AM, Eric Seidel wrote: I do not know the history as to why Chromium removed support for test_expectations cascading. Ideally we would have fewer test expectations, not more in the future. :) The cascading is really really useful for supporting multiple different Mac OS X versions with different results, and WebKit2 as an orthogonal dimension. Perhaps one possibility is to have something like an include directive in the expectations file, so the cascading can be defined by the expectations files themselves, rather than hardcoded in scripts. Regards, Maciej ___ 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] Adding ENABLE_FLEXBOX to WebCore
Sure, no problem. I'll rename it to ENALBE_NEW_FLEXBOX. On Fri, Jun 10, 2011 at 6:12 PM, Sam Weinig wei...@apple.com wrote: Since it is confusing to me (and may be to others), perhaps a different name than ENABLE_FLEXBOX should be used, given that we already have flexbox. Maybe, ENABLE_NEW_FLEXBOX? -Sam On Jun 10, 2011, at 2:42 PM, David Hyatt wrote: Just so people know, it was my recommendation that they just start with a new renderer and implementation. Some other recommendations I would make here (apologies if they have been implemented already): (1) Rename the current RenderFlexibleBox to put deprecated into the name, e.g., RenderDeprecatedFlexibleBox. (2) The old flexbox was never patched for vertical writing modes. Please make sure when you build the new renderer from the ground up that you take this into account. (3) Please consult with rendering experts for any changes you have to make to base classes, especially RenderBlock and RenderBox. We may be able to help simplify some of that code, especially compared to the old flexbox. (4) Use the old flexbox code as a rough guide, but be aware of its issues, e.g., too much layout when flexing, box-ordinal stuff is very slow, etc. I think some of the bugs you tried to fix already should inform this somewhat. Definitely keep rendering experts in the loop on this and have fun implementing! Dave On Jun 8, 2011, at 10:57 AM, Tony Chang wrote: Hi webkit-dev, I wanted to let you know that Ojan and I plan to add flexbox layout support to WebCore. WebCore already supports an older flexbox implementation (display: box), but the new spec is designed to be easier for developers to understand and more powerful. The old flexbox will still remain in WebCore since none of the CSS properties overlap with the new flexbox spec. The spec can be found at: http://www.w3.org/TR/css3-flexbox/ ( http://dev.w3.org/csswg/css3-flexbox/http://dev.w3.org/csswg/css3-flexbox/#negative-flexibility ) This support will be behind the ENABLE_FLEXBOX feature define ( https://bugs.webkit.org/show_bug.cgi?id=62049) and there is a meta bug tracking the feature's development ( https://bugs.webkit.org/show_bug.cgi?id=62048). I expect this feature to eventually be enabled by all ports. I am ready to setup a buildbot for tracking the compile and flexbox related layout tests. Should I go ahead and get this added to build.webkit.org's waterfall? Thanks, Tony ___ 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
Re: [webkit-dev] Adding ENABLE_FLEXBOX to WebCore
Err, ENABLE_NEW_FLEXBOX. On Mon, Jun 13, 2011 at 9:37 AM, Tony Chang t...@chromium.org wrote: Sure, no problem. I'll rename it to ENALBE_NEW_FLEXBOX. On Fri, Jun 10, 2011 at 6:12 PM, Sam Weinig wei...@apple.com wrote: Since it is confusing to me (and may be to others), perhaps a different name than ENABLE_FLEXBOX should be used, given that we already have flexbox. Maybe, ENABLE_NEW_FLEXBOX? -Sam On Jun 10, 2011, at 2:42 PM, David Hyatt wrote: Just so people know, it was my recommendation that they just start with a new renderer and implementation. Some other recommendations I would make here (apologies if they have been implemented already): (1) Rename the current RenderFlexibleBox to put deprecated into the name, e.g., RenderDeprecatedFlexibleBox. (2) The old flexbox was never patched for vertical writing modes. Please make sure when you build the new renderer from the ground up that you take this into account. (3) Please consult with rendering experts for any changes you have to make to base classes, especially RenderBlock and RenderBox. We may be able to help simplify some of that code, especially compared to the old flexbox. (4) Use the old flexbox code as a rough guide, but be aware of its issues, e.g., too much layout when flexing, box-ordinal stuff is very slow, etc. I think some of the bugs you tried to fix already should inform this somewhat. Definitely keep rendering experts in the loop on this and have fun implementing! Dave On Jun 8, 2011, at 10:57 AM, Tony Chang wrote: Hi webkit-dev, I wanted to let you know that Ojan and I plan to add flexbox layout support to WebCore. WebCore already supports an older flexbox implementation (display: box), but the new spec is designed to be easier for developers to understand and more powerful. The old flexbox will still remain in WebCore since none of the CSS properties overlap with the new flexbox spec. The spec can be found at: http://www.w3.org/TR/css3-flexbox/ (http://dev.w3.org/csswg/css3-flexbox/http://dev.w3.org/csswg/css3-flexbox/#negative-flexibility ) This support will be behind the ENABLE_FLEXBOX feature define ( https://bugs.webkit.org/show_bug.cgi?id=62049) and there is a meta bug tracking the feature's development ( https://bugs.webkit.org/show_bug.cgi?id=62048). I expect this feature to eventually be enabled by all ports. I am ready to setup a buildbot for tracking the compile and flexbox related layout tests. Should I go ahead and get this added to build.webkit.org's waterfall? Thanks, Tony ___ 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
Re: [webkit-dev] Adding ENABLE_FLEXBOX to WebCore
On Thu, Jun 9, 2011 at 3:55 PM, Maciej Stachowiak m...@apple.com wrote: On Jun 9, 2011, at 3:00 PM, Tony Chang wrote: On Thu, Jun 9, 2011 at 1:19 PM, Sam Weinig wei...@apple.com wrote: If the issue is the syntax for describing flexing, perhaps the spec should be written in a backwards compatible way, that supports both the new syntax and the old syntax, but the underlying implementation can remain. The new syntax describes a superset of features provided by the old syntax. I think it's possible to implement the old flexbox on top of the new flexbox implementation and that seems like a worthwhile goal, but it'll probably easier to see the similarities for refactoring after the code has been written. If it's a superset then I would much prefer to see the old code incrementally enhanced to support the extended features and new syntax, then to first rewrite from scratch and merge. Maybe the right step 1 is refactoring and cleaning up the old code. Rewriting from scratch throws away accumulated knowledge, and in cases where we have to keep the old implementation too, bloats the code. The decision to start from scratch was based on a recommendation by Hyatt on IRC to just rename the old implementation (to RenderDeprecatedFlexibleBox or something) and make a new implementation of RenderFlexibleBox. I can try to incrementally improve the existing code, but I think that'll hinder the design of the new code. For example, when writing the new code, I plan on adding the CSS properties flex-direction, flex-order, and flex-pack incrementally (separate patches for each, maybe multiple for flex-direction). Since the old flexbox code has slightly different variations of these already implemented, I would have to run the code for them on the old code path but not the new code path. While I think this is technically possible, I think it'll be tricky to get right. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding ENABLE_FLEXBOX to WebCore
On Thu, Jun 9, 2011 at 1:19 PM, Sam Weinig wei...@apple.com wrote: Why should we implement this spec? We already have one flex box implementation that we can never remove (and corresponds closely to Firefox's) so it seems to me that we should work on standardizing that model. Adding a large bunch of code that duplicates existing functionality seems foolish. There was an attempt to standardize the old flexbox ( http://www.w3.org/TR/2009/WD-css3-flexbox-20090723/), but that effort seems to have fizzled. I attempted to write some patches to make WebKit's old flexbox implementation match that spec, but Hyatt recommended against that because it can only break sites that are targetting WebKit's existing flexbox implementation. WebKit's implementation and Firefox's implementation are different enough that the current uses of flexbox are mostly browser specific (e.g., dashboard widgets). If the issue is the syntax for describing flexing, perhaps the spec should be written in a backwards compatible way, that supports both the new syntax and the old syntax, but the underlying implementation can remain. The new syntax describes a superset of features provided by the old syntax. I think it's possible to implement the old flexbox on top of the new flexbox implementation and that seems like a worthwhile goal, but it'll probably easier to see the similarities for refactoring after the code has been written. On Jun 8, 2011, at 10:57 AM, Tony Chang wrote: Hi webkit-dev, I wanted to let you know that Ojan and I plan to add flexbox layout support to WebCore. WebCore already supports an older flexbox implementation (display: box), but the new spec is designed to be easier for developers to understand and more powerful. The old flexbox will still remain in WebCore since none of the CSS properties overlap with the new flexbox spec. The spec can be found at: http://www.w3.org/TR/css3-flexbox/ ( http://dev.w3.org/csswg/css3-flexbox/http://dev.w3.org/csswg/css3-flexbox/#negative-flexibility ) This support will be behind the ENABLE_FLEXBOX feature define ( https://bugs.webkit.org/show_bug.cgi?id=62049) and there is a meta bug tracking the feature's development ( https://bugs.webkit.org/show_bug.cgi?id=62048). I expect this feature to eventually be enabled by all ports. I am ready to setup a buildbot for tracking the compile and flexbox related layout tests. Should I go ahead and get this added to build.webkit.org's waterfall? Thanks, Tony ___ 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] Adding ENABLE_FLEXBOX to WebCore
Hi webkit-dev, I wanted to let you know that Ojan and I plan to add flexbox layout support to WebCore. WebCore already supports an older flexbox implementation (display: box), but the new spec is designed to be easier for developers to understand and more powerful. The old flexbox will still remain in WebCore since none of the CSS properties overlap with the new flexbox spec. The spec can be found at: http://www.w3.org/TR/css3-flexbox/ ( http://dev.w3.org/csswg/css3-flexbox/http://dev.w3.org/csswg/css3-flexbox/#negative-flexibility ) This support will be behind the ENABLE_FLEXBOX feature define ( https://bugs.webkit.org/show_bug.cgi?id=62049) and there is a meta bug tracking the feature's development ( https://bugs.webkit.org/show_bug.cgi?id=62048). I expect this feature to eventually be enabled by all ports. I am ready to setup a buildbot for tracking the compile and flexbox related layout tests. Should I go ahead and get this added to build.webkit.org's waterfall? Thanks, Tony ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding ENABLE_FLEXBOX to WebCore
Maybe, it would involve disabling CSS parser rules at runtime. I don't think we have any code that currently tries to do this. On Wed, Jun 8, 2011 at 11:41 AM, Darin Fisher da...@chromium.org wrote: Is it possible for this feature to be enabled at runtime? On Jun 8, 2011 11:38 AM, Adam Barth aba...@webkit.org wrote: New features should be tested incrementally as they are developed. That means running them on build.webkit.org. The decision to ship a feature is separate. Adam On Wed, Jun 8, 2011 at 11:33 AM, Ojan Vafai o...@chromium.org wrote: I don't think we want to ship this until we have a reasonably feature complete implementation of the spec and that we're convinced the spec is stable. I expect that in implementing this we'll find areas of the spec that need reworking, but at this point it's mainly blocked on implementation experience. I'm not sure it's worth setting a bot up just for this, although I'm not opposed to it. I expect we should have this shippable within a couple months. Ojan On Wed, Jun 8, 2011 at 11:21 AM, Adam Barth aba...@webkit.org wrote: Can't we just define ENABLE_FLEXBOX on one or more of the commonly used ports and use the regular bots? Adam On Wed, Jun 8, 2011 at 10:57 AM, Tony Chang t...@chromium.org wrote: Hi webkit-dev, I wanted to let you know that Ojan and I plan to add flexbox layout support to WebCore. WebCore already supports an older flexbox implementation (display: box), but the new spec is designed to be easier for developers to understand and more powerful. The old flexbox will still remain in WebCore since none of the CSS properties overlap with the new flexbox spec. The spec can be found at: http://www.w3.org/TR/css3-flexbox/ ( http://dev.w3.org/csswg/css3-flexbox/) This support will be behind the ENABLE_FLEXBOX feature define (https://bugs.webkit.org/show_bug.cgi?id=62049) and there is a meta bug tracking the feature's development (https://bugs.webkit.org/show_bug.cgi?id=62048). I expect this feature to eventually be enabled by all ports. I am ready to setup a buildbot for tracking the compile and flexbox related layout tests. Should I go ahead and get this added to build.webkit.org's waterfall? Thanks, Tony ___ 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
Re: [webkit-dev] Cross-platform fonts for Layout Tests
Perhaps, but in practice, it's not enough. Here's an ahem pixel test that is slightly different on Mac and Chromium Linux: http://trac.webkit.org/browser/trunk/LayoutTests/platform/mac/fast/block/basic/010-expected.png http://trac.webkit.org/browser/trunk/LayoutTests/platform/chromium-linux/fast/block/basic/010-expected.png Also, I think it would be hard to tell by examining the HTML if a test uses another font. For example, the line height of an empty block might depend on the default font that isn't specified (does pre/pre render the same height on all platforms?). On Thu, Jun 2, 2011 at 10:44 AM, Adam Barth aba...@webkit.org wrote: I thought the whole point of Ahem was to avoid those problems. Adam On Thu, Jun 2, 2011 at 1:29 AM, Hao Zheng zheng...@chromium.org wrote: Actually, even the same Ahem font will be rendered differently on different platform, depending on the font drawing library, the anti-aliasing algorithm, subpixel, tiny float-point calculation diff on different arch. On Thu, Jun 2, 2011 at 3:30 AM, Eric Seidel e...@webkit.org wrote: I know that Ahem is safe to use across multiple platforms (the font metrics will be the same). Do we know if there are any other fonts for which this is true? I'd like to make the style-bot yell at people when they use pixel tests with non-safe fonts. Right now that list would only include ahem. -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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] checksum files are no longer used by layout tests
I've just committed the change to run-webkit-tests (old and new) to have it ignore .checksum files and instead read image checksums from png files. This is why there were big checkouts during the last few days as I was updating the old .png files to have checksums embedded. I'll be doing a follow up commit that deletes all the existing .checksum files from the tree since they are no longer needed. This should involve no action on your part. run-webkit-tests (old and new) should no longer generate .checksum files for new tests or when using --reset-results. If you have a patch already created that includes a .checksum file, it's OK to commit it. run-webkit-tests will ignore the .checksum file and I will come by later and delete the .checksum file. As a reminder, if you need to actually see the checksum value, you can use Tools/Scripts/read-checksum-from-png. Let me know if you see any problems. tony ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] embedding pixel result checksum in the png
I propose that we move away from checking in separate .checksum files for pixel tests and instead embed the checksum in the .png file as a comment. There are two main benefits of doing this: 1) Less files in the tree - faster git/svn operations. Currently, in LayoutTests, 32,650 out of 141,170 files are checksum files (23% of the files). 2) Less likely to accidentally check in a .checksum without a .png or a .png without a .checksum. We're currently trying this out in the Chromium port, but I would like to add this to the other ports as well. To make embedded checksums easier to use, I've added a script Tools/Scripts/read-checksum-from-png that will read the checksum from a png file passed in on the command line. I've also updated the flakiness dashboard and plan on updating PrettyPrint.rb so you can see the checksums in a diff. If there are other tools or workflows that might be interrupted by this change, please let me know and I will update those tools as well. If there are no objections to this, my plan is as follows: a) Update DRT to write the checksum to png files. b) Update run-webkit-tests to read the checksum from png files if the .checksum file is absent. c) Update webkit-patch rebaseline to not copy over the .checksum file. d) Update run-webkit-tests --reset-results and --new-baseline to not write .checksum files. e) Start converting old results to the new format (i.e., put the checksum in the png and delete the .checksum file). Thoughts or suggestions for improvement? tony ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] embedding pixel result checksum in the png
Yes, reading the checksum is the same speed as before. We write the png comment at the beginning of the file and only scan the first 2k of the file for the checksum. I also tried converting about 200 tests to use embedded checksums and found no speed difference. I've already updated new-run-webkit-tests, but plan on updating old-run-webkit-tests as well since it's a small amount of code (only about 20 lines of python, I imagine the amount of perl will be similar). On Tue, Apr 5, 2011 at 3:55 PM, Darin Adler da...@apple.com wrote: Sounds like a great idea, as long as reading the checksum is still fast. I couldn’t tell when you mentioned run-webkit-tests in your steps what your specific plans are for old-run-webkit-tests and new-run-webkit-tests. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Supporting css ime-mode property
On Tue, Oct 5, 2010 at 9:27 AM, Alexey Proskuryakov a...@webkit.org wrote: So far, the only accurate use case that I've seen was developing a UI for a back-end that doesn't support non-ASCII characters in some fields. I don't think we should extend the Web platform just to support apps that aren't i18n-aware. And anyway, you can always paste into any field, so css-mode doesn't protect you from getting non-ASCII characters in these fields. This seems to be the primary reason for the ime-mode property. It's common in forms on Japanese web sites to require that the input is formatted a certain way. For example, a site may require a phone number to be in ASCII (1234-5678) instead of unicode (１２３４ー５６７８). The web site will still enforces this by providing server side validation, but as a convenience, it may use ime-mode: disabled to avoid a server round trip. You could argue that the web site is broken because it should be able to normalize this on the server, but that doesn't change the fact that there are lots of web sites in Japan that already try to do this. Implementing ime-mode would improve the user experience on these sites. tony ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] deduplicate-results
I removed all of chromium's duplicate results, which was a bulk of the duplicates. I think there were a total of about 670 duplicate files and I deleted about 500 or so. The remaining duplicates are mostly cases where the same result file is in mac and mac-leopard. I can delete those on Monday. There aren't as many duplicates as I thought. 670 is a lot, but not compared to the 90,000+ files in LayoutTests. On Sat, Aug 28, 2010 at 10:47 AM, Eric Seidel e...@webkit.org wrote: I'm very glad to see work being done to remove some of our redundant layout test results: http://trac.webkit.org/changeset/66124 I'm curious what the status of that work is. Do we expect all duplicates are gone now? or just chromium's? -eric ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] W3C Proposal: User Interface Independence for Accessible Rich Internet Applications
Hi Chris, I'm curious what elements the UIRequestEvents apply to. Does it fire at the document level or does it fire for specific elements like textareas? The addition of undo/redo is similar to the proposal to add this to the textInput event. There was some discussion of that here: http://lists.w3.org/Archives/Public/www-dom/2010AprJun/0082.html http://lists.w3.org/Archives/Public/www-dom/2010AprJun/0082.htmlOjan also proposed renaming the textInput event to just beforeInput because it seems like it can apply to more than just text (e.g., undo'ing the insertion of an image). Do you think the use of textInput/beforeInput would meet the use cases needed by UIRequestEvent? Tony On Thu, Sep 2, 2010 at 5:34 PM, Chris Fleizach cfleiz...@apple.com wrote: Hello WebKit, James and I have been working on a W3C proposal to address some shortcomings we've noticed in terms of dealing with ScreenReaders and magnifiers in the wild wild web. It's aim is to add JavaScript capabilities to window.navigator and new AccessibilityEvents so that web developers are able to make web pages that interact with assistive technology to a degree they cannot today. If you're interested in accessibility, please take a look and send any feedback to us, or to these w3c lists (wai-xtech, www-dom, public-canvas-api, and public-html-comments) it was posted to *User Interface Independence for Accessible Rich Internet Applications* *W3C Proposal: 30 August 2010* http://lists.w3.org/Archives/Public/wai-xtech/2010Aug/att-0079/UserInterfaceIndependence.html PS: I had originally submitted a patch for half of this proposal, but we decided it would be best to make this public before landing it in webkit. https://bugs.webkit.org/show_bug.cgi?id=43005 ___ 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] [webkit-changes] [61728] trunk
Yes: https://bugs.webkit.org/show_bug.cgi?id=31387 . I will update the Skipped file to include a link to the bug. On Fri, Jun 25, 2010 at 2:14 AM, Alexey Proskuryakov a...@webkit.org wrote: 23.06.2010, в 19:54, t...@chromium.org написал(а): --- trunk/LayoutTests/platform/mac/Skipped2010-06-24 02:21:48 UTC (rev 61727) +++ trunk/LayoutTests/platform/mac/Skipped2010-06-24 02:54:20 UTC (rev 61728)++# Hits an assert in FrameLoader.cpp. +http/tests/multipart/policy-ignore-crash.php Is there a bug tracking this issue? - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
