Re: [webkit-dev] build.webkit.org down

2013-01-25 Thread Tony Chang
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

2013-01-24 Thread Tony Chang
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?

2012-11-13 Thread Tony Chang
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?

2012-11-13 Thread Tony Chang
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

2012-09-26 Thread Tony Chang
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.

2012-07-19 Thread Tony Chang
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?

2012-02-24 Thread Tony Chang
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

2011-12-01 Thread Tony Chang
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

2011-11-18 Thread Tony Chang
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

2011-11-17 Thread Tony Chang
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

2011-11-17 Thread Tony Chang
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] Tools/Scripts/webkit-patch rebaseline-expectations does not launch html comparison page?

2011-11-08 Thread Tony Chang
On Tue, Nov 8, 2011 at 12:00 PM, Elliot Poger epo...@chromium.org wrote:

 Perhaps I should approach this from a different angle:

 What is the recommended procedure for:
 - generating new baseline images for a few dozen failing tests, on various
 platforms


webkit-patch rebaseline-expectations


 - visually inspecting them to make sure they're not bogus


Would 'webkit-patch pretty-diff' work for you?  It should show the files
being added/deleted, but it won't generate a pixel diff.


 - committing them, along with test_expectations changes, to the WebKit repo


webkit-patch land
___
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

2011-11-04 Thread Tony Chang
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)

2011-07-07 Thread Tony Chang
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

2011-06-13 Thread Tony Chang
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

2011-06-13 Thread Tony Chang
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

2011-06-10 Thread Tony Chang
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

2011-06-09 Thread Tony Chang
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

2011-06-08 Thread Tony Chang
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

2011-06-08 Thread Tony Chang
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] Adding ENABLE_FLEXBOX to WebCore

2011-06-08 Thread Tony Chang
I don't understand how changing the name prevents the feature from being
shipped half-done.  If we're going to ship a half-done feature, we may as
well use the vendor prefixed name so sites don't depend on the goofy name.

However, I'm willing to run a buildbot for this and that seems better than
shipping a half-done feature.  I don't expect it to be a core builder and
Ojan and I will be the ones keeping it green.  Isn't this what we're doing
for other features like CSS Regions and Exclusions?

On Wed, Jun 8, 2011 at 12:02 PM, Adam Barth aba...@webkit.org wrote:

 It seems like the simplest thing is to have an ENABLE macro that's
 turned on and to use the normal bots.  If you're really worried about
 folks shipping the feature half-done by accident, you can use a goofy
 name like -webkit-goofybox (or whatever) and rename it to the final
 name when you're ready.

 Adam


 On Wed, Jun 8, 2011 at 11:50 AM, Ojan Vafai o...@chromium.org wrote:
  Kind of. We could make the functionality only work at runtime, but adding
  the properties to the CSS parser would be difficult to make runtime
  configurable. So, the CSS properties would parse correctly but do
 nothing.
  That's especially problematic for properties like display that would
 then
  get an invalid value.
  My current plan was still to test this incrementally. We'd include tests
 as
  we went, but skip the flexbox subdirectory. We would just run the tests
  locally during development. This has the downside that other changes
 might
  break the flexbox tests, but thats a pain I'm willing to live with.
  I'm fine doing this differently if people have strong opinions.
  Ojan
 
  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

2011-06-02 Thread Tony Chang
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

2011-04-21 Thread Tony Chang
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

2011-04-05 Thread Tony Chang
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

2011-04-05 Thread Tony Chang
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

2010-10-05 Thread Tony Chang
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 (1234ー5678).  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

2010-09-03 Thread Tony Chang
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

2010-09-03 Thread Tony Chang
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

2010-06-24 Thread Tony Chang
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