Import w3c tests for the service workers

Import w3c tests for the service workers

This patch imports wpt tests @357b83b809e3cbc7a1805e7c3ca108a7980d782f. Many
failures are left as is, so we should file each bugs after this lands.

BUG=602693, 618616, 624278, 571722, 617886
TEST=./third_party/WebKit/Tools/Scripts/run-webkit-tests -f -t Debug --enable-wptserve imported/wpt/service-workers

Committed: https://crrev.com/a4ed034738fe6c86c262e5cb0466b79ca84ab65f
Cr-Commit-Position: refs/heads/master@{#426405}

[shimazu, 2016-10-13 03:03:25]

shimazu@chromium.org changed reviewers:
+ falken@chromium.org

[shimazu, 2016-10-13 03:03:28]

ptal:)

[shimazu, 2016-10-13 03:59:51]

shimazu@chromium.org changed reviewers:
+ tkent@chromium.org

[shimazu, 2016-10-13 03:59:52]

tkent: could you also take a look?

[tkent, 2016-10-13 04:05:19]

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

[commit-bot: I haz the power, 2016-10-13 04:05:40]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[falken, 2016-10-13 04:26:37]

Thanks for working on this!

https://codereview.chromium.org/2415873002/diff/1/third_party/WebKit/LayoutTe...
File third_party/WebKit/LayoutTests/TestExpectations (right):

https://codereview.chromium.org/2415873002/diff/1/third_party/WebKit/LayoutTe...
third_party/WebKit/LayoutTests/TestExpectations:1226: # wpt/service-workers
nit: The TODO doesn't seem informative, we know bug 604693 needs to be fixed. I
would remove.

https://codereview.chromium.org/2415873002/diff/1/third_party/WebKit/LayoutTe...
third_party/WebKit/LayoutTests/TestExpectations:1237: crbug.com/602693
imported/wpt/service-workers/cache-storage/worker/cache-storage.https.html [
Failure ]
I think cache-storage should be tracked in a different bug. These should be
owned by the storage team. Actually for starters we might just not import these
yet.

https://codereview.chromium.org/2415873002/diff/1/third_party/WebKit/LayoutTe...
File third_party/WebKit/LayoutTests/W3CImportExpectations (right):

https://codereview.chromium.org/2415873002/diff/1/third_party/WebKit/LayoutTe...
third_party/WebKit/LayoutTests/W3CImportExpectations:296: #
imported/wpt/service-workers [ Pass ]
This comment out format is confusing. tkent what is the convention here? What is
the difference between

# imported/wpt/service-workers [ Pass ]
and 
imported/wpt/service-workers [ Pass ]

[tkent, 2016-10-13 04:48:22]

> TEST=./third_party/WebKit/Tools/Scripts/run-webkit-tests -f -t Debug
--enable-wptserve imported/wpt/service-workers

--enable-wptserve isn't specified in buildbots.  Please adjust TestExpectations
without --enable-wptserve.

https://codereview.chromium.org/2415873002/diff/1/third_party/WebKit/LayoutTe...
File third_party/WebKit/LayoutTests/W3CImportExpectations (right):

https://codereview.chromium.org/2415873002/diff/1/third_party/WebKit/LayoutTe...
third_party/WebKit/LayoutTests/W3CImportExpectations:296: #
imported/wpt/service-workers [ Pass ]
On 2016/10/13 at 04:26:37, falken wrote:
> This comment out format is confusing. tkent what is the convention here? What
is the difference between
> 
> # imported/wpt/service-workers [ Pass ]
> and 
> imported/wpt/service-workers [ Pass ]

The convention is to prepend '# '.  I don't know if W3CImportExpectations
supports anything other than 'Skip'.

[falken, 2016-10-13 04:53:40]

https://codereview.chromium.org/2415873002/diff/1/third_party/WebKit/LayoutTe...
File third_party/WebKit/LayoutTests/W3CImportExpectations (right):

https://codereview.chromium.org/2415873002/diff/1/third_party/WebKit/LayoutTe...
third_party/WebKit/LayoutTests/W3CImportExpectations:296: #
imported/wpt/service-workers [ Pass ]
On 2016/10/13 04:48:21, tkent wrote:
> On 2016/10/13 at 04:26:37, falken wrote:
> > This comment out format is confusing. tkent what is the convention here?
What
> is the difference between
> > 
> > # imported/wpt/service-workers [ Pass ]
> > and 
> > imported/wpt/service-workers [ Pass ]
> 
> The convention is to prepend '# '.  I don't know if W3CImportExpectations
> supports anything other than 'Skip'.

Ah OK. I saw some Pass expectations (wpt/dom, wpt/svg) which was confusing.

[shimazu, 2016-10-13 05:31:07]

On 2016/10/13 04:48:22, tkent wrote:
> > TEST=./third_party/WebKit/Tools/Scripts/run-webkit-tests -f -t Debug
> --enable-wptserve imported/wpt/service-workers
> 
> --enable-wptserve isn't specified in buildbots.  Please adjust
TestExpectations
> without --enable-wptserve.

Do you have any plan to enable --enable-wptserve in imported/wpt by default?
Most of tests for the service workers fail w/o the flag, and once adjust the
expectation, "WebKit Linux -WPTServe" bot, which is what we actually want to
see, will be kept failing.
Is it too early to import these tests?

>
https://codereview.chromium.org/2415873002/diff/1/third_party/WebKit/LayoutTe...
> File third_party/WebKit/LayoutTests/W3CImportExpectations (right):
> 
>
https://codereview.chromium.org/2415873002/diff/1/third_party/WebKit/LayoutTe...
> third_party/WebKit/LayoutTests/W3CImportExpectations:296: #
> imported/wpt/service-workers [ Pass ]
> On 2016/10/13 at 04:26:37, falken wrote:
> > This comment out format is confusing. tkent what is the convention here?
What
> is the difference between
> > 
> > # imported/wpt/service-workers [ Pass ]
> > and 
> > imported/wpt/service-workers [ Pass ]
> 
> The convention is to prepend '# '.  I don't know if W3CImportExpectations
> supports anything other than 'Skip'.

[tkent, 2016-10-13 06:13:30]

On 2016/10/13 at 05:31:07, shimazu wrote:
> On 2016/10/13 04:48:22, tkent wrote:
> > > TEST=./third_party/WebKit/Tools/Scripts/run-webkit-tests -f -t Debug
> > --enable-wptserve imported/wpt/service-workers
> > 
> > --enable-wptserve isn't specified in buildbots.  Please adjust
TestExpectations
> > without --enable-wptserve.
> 
> Do you have any plan to enable --enable-wptserve in imported/wpt by default?

No one is working on it for now.
The major blockers are crbug.com/627008 and crbug.com/623613, I think.  Your
contribution is definitely welcome.

[falken, 2016-10-13 06:21:25]

On 2016/10/13 06:13:30, tkent wrote:
> On 2016/10/13 at 05:31:07, shimazu wrote:
> > On 2016/10/13 04:48:22, tkent wrote:
> > > > TEST=./third_party/WebKit/Tools/Scripts/run-webkit-tests -f -t Debug
> > > --enable-wptserve imported/wpt/service-workers
> > > 
> > > --enable-wptserve isn't specified in buildbots.  Please adjust
> TestExpectations
> > > without --enable-wptserve.
> > 
> > Do you have any plan to enable --enable-wptserve in imported/wpt by default?
> 
> No one is working on it for now.
> The major blockers are crbug.com/627008 and crbug.com/623613, I think.  Your
> contribution is definitely welcome.

In the short-term is it possible to do something like this:

in TestExpectations:
# WontFix, serviceworkers requires wptserve.
imported/wpt/serviceworkers [ Skip ]

in WPTServeExpectations:
crbug.com/xxx imported/wpt/serviceworkers/test-that-fails1 [ Failure ]
crbug.com/xxx imported/wpt/serviceworkers/test-that-fails2 [ Failure ]

[shimazu, 2016-10-13 07:08:40]

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

[shimazu, 2016-10-13 07:08:42]

Thanks, what is described at the issue of pointerevents looks the same problem
with our tests.
For now I moved the expectations from TestExpectation to WPTServeExpectations as
falken said. 

jsbell@: Can I add tests for cache storages at the same time?

https://codereview.chromium.org/2415873002/diff/1/third_party/WebKit/LayoutTe...
File third_party/WebKit/LayoutTests/TestExpectations (right):

https://codereview.chromium.org/2415873002/diff/1/third_party/WebKit/LayoutTe...
third_party/WebKit/LayoutTests/TestExpectations:1226: # wpt/service-workers
On 2016/10/13 04:26:36, falken wrote:
> nit: The TODO doesn't seem informative, we know bug 604693 needs to be fixed.
I
> would remove.

Done.

https://codereview.chromium.org/2415873002/diff/1/third_party/WebKit/LayoutTe...
third_party/WebKit/LayoutTests/TestExpectations:1237: crbug.com/602693
imported/wpt/service-workers/cache-storage/worker/cache-storage.https.html [
Failure ]
On 2016/10/13 04:26:36, falken wrote:
> I think cache-storage should be tracked in a different bug. These should be
> owned by the storage team. Actually for starters we might just not import
these
> yet.

Acknowledged.

[jsbell, 2016-10-13 16:18:21]

Description was changed from

==========
Import w3c tests for the service workers

This patch imports wpt tests @357b83b809e3cbc7a1805e7c3ca108a7980d782f. Many
failures are left as is, so we should file each bugs after this lands.

BUG=602693,618616,624278,571722,617886
TEST=./third_party/WebKit/Tools/Scripts/run-webkit-tests -f -t Debug
--enable-wptserve imported/wpt/service-workers
==========

to

==========
Import w3c tests for the service workers

This patch imports wpt tests @357b83b809e3cbc7a1805e7c3ca108a7980d782f. Many
failures are left as is, so we should file each bugs after this lands.

BUG=602693,618616,624278,571722,617886
TEST=./third_party/WebKit/Tools/Scripts/run-webkit-tests -f -t Debug
--enable-wptserve imported/wpt/service-workers
==========

[jsbell, 2016-10-13 16:18:21]

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

[jsbell, 2016-10-13 16:19:40]

On 2016/10/13 07:08:42, shimazu wrote:
> jsbell@: Can I add tests for cache storages at the same time?

I'm mostly okay with bringing these in at the same time, but this is a LOT of
tests to bring it at once and there will be a tail to this (e.g. teaching the
wptroller to [Skip] these in TestExpectations]. So doing a subset (i.e. SW but
not CS) first makes more sense to me.

If we have these marked as [Skip] in TestExpectations, can we have expected.txt
files and [Pass] instead of [Failure] in WPTServeExpectations?

[shimazu, 2016-10-14 05:05:33]

On 2016/10/13 16:19:40, jsbell wrote:
> On 2016/10/13 07:08:42, shimazu wrote:
> > jsbell@: Can I add tests for cache storages at the same time?
> 
> I'm mostly okay with bringing these in at the same time, but this is a LOT of
> tests to bring it at once and there will be a tail to this (e.g. teaching the
> wptroller to [Skip] these in TestExpectations]. So doing a subset (i.e. SW but
> not CS) first makes more sense to me.
> 
> If we have these marked as [Skip] in TestExpectations, can we have
expected.txt
> files and [Pass] instead of [Failure] in WPTServeExpectations?

Thanks, I got it. Removed the cache storage tests for now.

[falken, 2016-10-17 05:27:04]

> If we have these marked as [Skip] in TestExpectations, can we have
expected.txt
> files and [Pass] instead of [Failure] in WPTServeExpectations?

I'm curious why expected.txt is better than [Failure]? It seems like having
[Failure] in WPTServeExpectations makes it easier to track which tests are
failing: otherwise [Pass] could mean passing or failing.

https://codereview.chromium.org/2415873002/diff/60001/third_party/WebKit/Layo...
File third_party/WebKit/LayoutTests/WPTServeExpectations (right):

https://codereview.chromium.org/2415873002/diff/60001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/WPTServeExpectations:168: crbug.com/602693
imported/wpt/service-workers/stub-4.7.4.1-fetch-event-section.html [ Failure ]
Can we just skip the stub tests for this patch, because they seem mostly empty?
It'll help split up this huge patch. I also don't know if they are being
maintained at all.

[shimazu, 2016-10-17 07:40:27]

> I'm curious why expected.txt is better than [Failure]? It seems like having
> [Failure] in WPTServeExpectations makes it easier to track which tests are
> failing: otherwise [Pass] could mean passing or failing.

I guess it's because expected.txt can describe per-test failures, but I'd like
to hear the actual reason from jsbell@, too.

https://codereview.chromium.org/2415873002/diff/60001/third_party/WebKit/Layo...
File third_party/WebKit/LayoutTests/WPTServeExpectations (right):

https://codereview.chromium.org/2415873002/diff/60001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/WPTServeExpectations:168: crbug.com/602693
imported/wpt/service-workers/stub-4.7.4.1-fetch-event-section.html [ Failure ]
On 2016/10/17 05:27:04, falken wrote:
> Can we just skip the stub tests for this patch, because they seem mostly
empty?
> It'll help split up this huge patch. I also don't know if they are being
> maintained at all. 

I talked with falken offline, and we concluded to import these tests as is
because skipping the stub tests will also make W3CImportExpectation messy.
Let's wait for restarting the autoroller to clean this up.

[qyearsley, 2016-10-17 16:26:05]

On 2016/10/17 at 07:40:27, shimazu wrote:
> > I'm curious why expected.txt is better than [Failure]? It seems like having
> > [Failure] in WPTServeExpectations makes it easier to track which tests are
> > failing: otherwise [Pass] could mean passing or failing.
> 
> I guess it's because expected.txt can describe per-test failures, but I'd like
to hear the actual reason from jsbell@, too.

Note, according to
https://www.chromium.org/developers/testing/webkit-layout-tests/testexpectations,
it's also because:

  "The primary function of the LayoutTests is as a regression test suite; this
means that, while we
  care about whether a page is being rendered correctly, we care more about
whether the page is being
  rendered the way we expect it to. In other words, we look more for changes in
behavior than we do
  for correctness."

>
https://codereview.chromium.org/2415873002/diff/60001/third_party/WebKit/Layo...
> File third_party/WebKit/LayoutTests/WPTServeExpectations (right):
> 
>
https://codereview.chromium.org/2415873002/diff/60001/third_party/WebKit/Layo...
> third_party/WebKit/LayoutTests/WPTServeExpectations:168: crbug.com/602693
imported/wpt/service-workers/stub-4.7.4.1-fetch-event-section.html [ Failure ]
> On 2016/10/17 05:27:04, falken wrote:
> > Can we just skip the stub tests for this patch, because they seem mostly
empty?
> > It'll help split up this huge patch. I also don't know if they are being
> > maintained at all. 
> 
> I talked with falken offline, and we concluded to import these tests as is
because skipping the stub tests will also make W3CImportExpectation messy.
> Let's wait for restarting the autoroller to clean this up.

Note, the w3c-test-autoroller is currently blocked on http://crbug.com/656171;
it's failing to
import wpt/workers/semantics/encodings/004.worker.js because of an encoding or
patch-applying issue.

[jsbell, 2016-10-17 23:22:14]

On 2016/10/17 16:26:05, qyearsley wrote:
> On 2016/10/17 at 07:40:27, shimazu wrote:
> > > I'm curious why expected.txt is better than [Failure]? It seems like
having
> > > [Failure] in WPTServeExpectations makes it easier to track which tests are
> > > failing: otherwise [Pass] could mean passing or failing.
> > 
> > I guess it's because expected.txt can describe per-test failures, but I'd
like
> to hear the actual reason from jsbell@, too.
> 
> Note, according to
>
https://www.chromium.org/developers/testing/webkit-layout-tests/testexpectations,
> it's also because:
> 
>   "The primary function of the LayoutTests is as a regression test suite; this
> means that, while we
>   care about whether a page is being rendered correctly, we care more about
> whether the page is being
>   rendered the way we expect it to. In other words, we look more for changes
in
> behavior than we do
>   for correctness."

Right. [Pass] + expectations detects regressions and also lets us inspect the
actual PASS/FAIL lines in the file. For anything in imported/wpt/ the presence
of expected.txt indicates failure.

[shimazu, 2016-10-19 03:46:51]

Thanks for your comments!

falken: It seems fine for me to commit this as is. What do you think?

[falken, 2016-10-19 03:50:43]

On 2016/10/19 03:46:51, shimazu wrote:
> Thanks for your comments!
> 
> falken: It seems fine for me to commit this as is. What do you think?

Thanks for pinging. lgtm.

[shimazu, 2016-10-19 03:55:53]

The CQ bit was checked by shimazu@chromium.org

[commit-bot: I haz the power, 2016-10-19 03:57:39]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-10-19 04:17:31]

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

[commit-bot: I haz the power, 2016-10-19 04:17:34]

Try jobs failed on following builders:
  ios-device on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-device/builds...)

[shimazu, 2016-10-19 05:47:55]

The CQ bit was checked by shimazu@chromium.org

[shimazu, 2016-10-19 05:47:57]

The patchset sent to the CQ was uploaded after l-g-t-m from falken@chromium.org
Link to the patchset: https://codereview.chromium.org/2415873002/#ps80001
(title: "Rebase")

[commit-bot: I haz the power, 2016-10-19 05:49:11]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-10-19 10:07:14]

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

[commit-bot: I haz the power, 2016-10-19 10:07:16]

Try jobs failed on following builders:
  android_arm64_dbg_recipe on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_arm6...)
  android_clang_dbg_recipe on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_clan...)

[shimazu, 2016-10-20 01:49:58]

The CQ bit was checked by shimazu@chromium.org

[commit-bot: I haz the power, 2016-10-20 01:50:32]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-10-20 02:06:40]

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

[commit-bot: I haz the power, 2016-10-20 02:06:43]

Try jobs failed on following builders:
  android_clang_dbg_recipe on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_clan...)

[shimazu, 2016-10-20 03:22:50]

The CQ bit was checked by shimazu@chromium.org

[shimazu, 2016-10-20 03:22:51]

The patchset sent to the CQ was uploaded after l-g-t-m from falken@chromium.org
Link to the patchset:
https://chromiumcodereview.appspot.com/2415873002/#ps100001 (title: "Rebase")

[commit-bot: I haz the power, 2016-10-20 03:23:25]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-10-20 04:44:21]

Description was changed from

==========
Import w3c tests for the service workers

This patch imports wpt tests @357b83b809e3cbc7a1805e7c3ca108a7980d782f. Many
failures are left as is, so we should file each bugs after this lands.

BUG=602693,618616,624278,571722,617886
TEST=./third_party/WebKit/Tools/Scripts/run-webkit-tests -f -t Debug
--enable-wptserve imported/wpt/service-workers
==========

to

==========
Import w3c tests for the service workers

This patch imports wpt tests @357b83b809e3cbc7a1805e7c3ca108a7980d782f. Many
failures are left as is, so we should file each bugs after this lands.

BUG=602693,618616,624278,571722,617886
TEST=./third_party/WebKit/Tools/Scripts/run-webkit-tests -f -t Debug
--enable-wptserve imported/wpt/service-workers
==========

[commit-bot: I haz the power, 2016-10-20 04:44:24]

Committed patchset #6 (id:100001)

[Michael Achenbach, 2016-10-20 19:16:14]

machenbach@chromium.org changed reviewers:
+ machenbach@chromium.org

[Michael Achenbach, 2016-10-20 19:16:17]

Anything gone wrong when rebasing?

Hint: Add rebaseline expectations at a random location in this file - not in the
end - to avoid CL-rebase trouble.

https://chromiumcodereview.appspot.com/2415873002/diff/100001/third_party/Web...
File third_party/WebKit/LayoutTests/TestExpectations (right):

https://chromiumcodereview.appspot.com/2415873002/diff/100001/third_party/Web...
third_party/WebKit/LayoutTests/TestExpectations:1275: crbug.com/656622
inspector/sources/debugger-pause/debugger-eval-while-paused-throws.html [
NeedsManualRebaseline ]
Why is this here?

+clemens

[Clemens Hammacher, 2016-10-20 19:22:32]

clemensh@chromium.org changed reviewers:
+ clemensh@chromium.org

[Clemens Hammacher, 2016-10-20 19:22:35]

https://chromiumcodereview.appspot.com/2415873002/diff/100001/third_party/Web...
File third_party/WebKit/LayoutTests/TestExpectations (right):

https://chromiumcodereview.appspot.com/2415873002/diff/100001/third_party/Web...
third_party/WebKit/LayoutTests/TestExpectations:1275: crbug.com/656622
inspector/sources/debugger-pause/debugger-eval-while-paused-throws.html [
NeedsManualRebaseline ]
On 2016/10/20 19:16:17, machenbach (slow) wrote:
> Why is this here?
> 
> +clemens

Looks like a rebase problem. Should be fixed by changing it to NeedsRebaseline
(safer than just removing it).

[shimazu, 2016-10-21 04:21:20]

https://codereview.chromium.org/2415873002/diff/100001/third_party/WebKit/Lay...
File third_party/WebKit/LayoutTests/TestExpectations (right):

https://codereview.chromium.org/2415873002/diff/100001/third_party/WebKit/Lay...
third_party/WebKit/LayoutTests/TestExpectations:1275: crbug.com/656622
inspector/sources/debugger-pause/debugger-eval-while-paused-throws.html [
NeedsManualRebaseline ]
On 2016/10/20 19:22:34, Clemens Hammacher wrote:
> On 2016/10/20 19:16:17, machenbach (slow) wrote:
> > Why is this here?
> > 
> > +clemens
> 
> Looks like a rebase problem. Should be fixed by changing it to NeedsRebaseline
> (safer than just removing it).

Oops, it's definitely a rebasing problem. Sorry..
I created a CL to fix that.
https://crrev.com/2443513002

[Michael Achenbach, 2016-10-21 06:58:36]

https://codereview.chromium.org/2415873002/diff/100001/third_party/WebKit/Lay...
File third_party/WebKit/LayoutTests/TestExpectations (right):

https://codereview.chromium.org/2415873002/diff/100001/third_party/WebKit/Lay...
third_party/WebKit/LayoutTests/TestExpectations:1275: crbug.com/656622
inspector/sources/debugger-pause/debugger-eval-while-paused-throws.html [
NeedsManualRebaseline ]
On 2016/10/21 04:21:20, shimazu wrote:
> On 2016/10/20 19:22:34, Clemens Hammacher wrote:
> > On 2016/10/20 19:16:17, machenbach (slow) wrote:
> > > Why is this here?
> > > 
> > > +clemens
> > 
> > Looks like a rebase problem. Should be fixed by changing it to
NeedsRebaseline
> > (safer than just removing it).
> 
> Oops, it's definitely a rebasing problem. Sorry..
> I created a CL to fix that.
> https://crrev.com/2443513002

Thanks, I assume the line below is expected, right?

[commit-bot: I haz the power, 2016-10-21 13:15:37]

Description was changed from

==========
Import w3c tests for the service workers

This patch imports wpt tests @357b83b809e3cbc7a1805e7c3ca108a7980d782f. Many
failures are left as is, so we should file each bugs after this lands.

BUG=602693,618616,624278,571722,617886
TEST=./third_party/WebKit/Tools/Scripts/run-webkit-tests -f -t Debug
--enable-wptserve imported/wpt/service-workers
==========

to

==========
Import w3c tests for the service workers

This patch imports wpt tests @357b83b809e3cbc7a1805e7c3ca108a7980d782f. Many
failures are left as is, so we should file each bugs after this lands.

BUG=602693,618616,624278,571722,617886
TEST=./third_party/WebKit/Tools/Scripts/run-webkit-tests -f -t Debug
--enable-wptserve imported/wpt/service-workers

Committed: https://crrev.com/a4ed034738fe6c86c262e5cb0466b79ca84ab65f
Cr-Commit-Position: refs/heads/master@{#426405}
==========

[commit-bot: I haz the power, 2016-10-21 13:15:39]

Patchset 6 (id:??) landed as
https://crrev.com/a4ed034738fe6c86c262e5cb0466b79ca84ab65f
Cr-Commit-Position: refs/heads/master@{#426405}