Import wpt@5df9b57edb3307a87d5187804b29c8ddd2aa14e1

Import wpt@5df9b57edb3307a87d5187804b29c8ddd2aa14e1

Using update-w3c-deps in Chromium b6f4380493084007dc4237d28153c0dd3e5d520b.

Other things which were manually modified:

 - Paths updated in TestExpectations for web-animations tests.
 - A line was added in W3CImportExpectations to skip a test with non-ASCII encoding.
 - A line was added in W3CImportExpectations to skip a new directory.

[qyearsley, 2016-05-20 22:22:59]

qyearsley@chromium.org changed reviewers:
+ jsbell@chromium.org

[qyearsley, 2016-05-21 00:03:54]

The CQ bit was checked by qyearsley@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-05-21 00:04:23]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1999243002/20001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1999243002/20001

[commit-bot: I haz the power, 2016-05-21 01:10:05]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-05-21 01:10:06]

Dry run: Try jobs failed on following builders:
  linux_chromium_rel_ng on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[jsbell, 2016-05-23 15:50:08]

lgtm

[qyearsley, 2016-05-23 18:08:57]

On 2016/05/23 at 15:50:08, jsbell wrote:
> lgtm

Would it be safe and a good idea to add all failing tests to TestExpectations
with NeedsRebaseline? I imagine most/all of them are cases where there are new
testharness.js tests and some of the assertions are failing so an -expected.txt
is required. Maybe the best thing is to get the non-platform-specific baselines
locally first?

[qyearsley, 2016-05-23 18:33:07]

On 2016/05/23 at 18:08:57, qyearsley wrote:
> On 2016/05/23 at 15:50:08, jsbell wrote:
> > lgtm
> 
> Would it be safe and a good idea to add all failing tests to TestExpectations
with NeedsRebaseline? I imagine most/all of them are cases where there are new
testharness.js tests and some of the assertions are failing so an -expected.txt
is required. Maybe the best thing is to get the non-platform-specific baselines
locally first?

I think there are some new failures that may be unexpected -- do you think there
would be value in splitting this into multiple changes reviewed by individual
people interested in imported/wpt subdirectories? Or would it be better to
update everything, get the new baselines, and then make sure everyone knows
about any new failures (new baselines)?

[jsbell, 2016-05-23 21:11:36]

> Would it be safe and a good idea to add all failing tests to TestExpectations
> with NeedsRebaseline? I imagine most/all of them are cases where there are new
> testharness.js tests and some of the assertions are failing so an
-expected.txt
> is required. Maybe the best thing is to get the non-platform-specific
baselines
> locally first?

Are the failures platform specific? That's usually rare with wpt tests. 

I usually do try and generate the expected results locally first.
 
> I think there are some new failures that may be unexpected -- do you think
there
> would be value in splitting this into multiple changes reviewed by individual
> people interested in imported/wpt subdirectories? Or would it be better to
> update everything, get the new baselines, and then make sure everyone knows
> about any new failures (new baselines)?

Update, then notify everyone. There's a spreadsheet that tracks failures
(tkent/kojii maintain it?)

[qyearsley, 2016-05-23 22:04:25]

On 2016/05/23 at 21:11:36, jsbell wrote:
> > Would it be safe and a good idea to add all failing tests to
TestExpectations
> > with NeedsRebaseline? I imagine most/all of them are cases where there are
new
> > testharness.js tests and some of the assertions are failing so an
-expected.txt
> > is required. Maybe the best thing is to get the non-platform-specific
baselines
> > locally first?
> 
> Are the failures platform specific? That's usually rare with wpt tests. 
> 
> I usually do try and generate the expected results locally first.
> 

Is there an easier way to do this that I'm missing? I've tried:

  `run-webkit-tests --new-test-results <test>` doesn't write the new expected
results
  `run-webkit-tests --new-baseline <test>` writes to the platform-specific
directory
  `webkit-patch rebaseline-server` UI didn't provide an obvious way to write new
expected results
  `webkit-patch rebaseline-test-internal
--results-directory=<local-results-dir>` requires a builder name, and if one is
given, writes to the platform-specific directory
  `webkit-patch rebaseline-json` doesn't accept full_results.json or
failing_results.json as inputs

[Dirk Pranke, 2016-05-23 22:08:11]

On 2016/05/23 22:04:25, qyearsley wrote:
> On 2016/05/23 at 21:11:36, jsbell wrote:
> > > Would it be safe and a good idea to add all failing tests to
> TestExpectations
> > > with NeedsRebaseline? I imagine most/all of them are cases where there are
> new
> > > testharness.js tests and some of the assertions are failing so an
> -expected.txt
> > > is required. Maybe the best thing is to get the non-platform-specific
> baselines
> > > locally first?
> > 
> > Are the failures platform specific? That's usually rare with wpt tests. 
> > 
> > I usually do try and generate the expected results locally first.
> > 
> 
> Is there an easier way to do this that I'm missing? I've tried:
> 
>   `run-webkit-tests --new-test-results <test>` doesn't write the new expected
> results
>   `run-webkit-tests --new-baseline <test>` writes to the platform-specific
> directory
>   `webkit-patch rebaseline-server` UI didn't provide an obvious way to write
new
> expected results
>   `webkit-patch rebaseline-test-internal
> --results-directory=<local-results-dir>` requires a builder name, and if one
is
> given, writes to the platform-specific directory
>   `webkit-patch rebaseline-json` doesn't accept full_results.json or
> failing_results.json as inputs

For existing tests, --reset-results should update the -expected.* files.

For new tests, --new-test-results should write files if needed, but it will 
write them into platform/{mac,win,linux}. --new-baseline will write them
into platform/{mac,win,linux}-$ver instead. 

I don't think there's a way to write new generic results offhand. I don't recall

why not.

rebaseline-server *should* give you a way to pull baselines down from the bots,
if they 
exist (which they won't for new tests).

[qyearsley, 2016-05-24 01:03:03]

The CQ bit was checked by qyearsley@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-05-24 01:03:36]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1999243002/60001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1999243002/60001

[commit-bot: I haz the power, 2016-05-24 02:29:57]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-05-24 02:30:00]

Dry run: Try jobs failed on following builders:
  mac_chromium_rel_ng on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[qyearsley, 2016-05-26 23:36:15]

On 2016/05/24 at 02:30:00, commit-bot wrote:
> Dry run: Try jobs failed on following builders:
>   mac_chromium_rel_ng on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

The main reason why I haven't been trying to commit this in the past couple days
is because getting the new baselines will be easier once I modify webkit-patch
rebaseline to download all new baselines from a try job (related to
http://crbug.com/474273).

I assume this isn't blocking anyone?

[qyearsley, 2016-05-27 15:31:47]

Not necessary anymore (import already done by
https://codereview.chromium.org/1999243002), closing.