Refactor ServiceWorker tests for inclusion in WPT

Upstream service worker nav. preload tests to WPT

BUG=688116
R=falken@chromium.org

Review-Url: https://codereview.chromium.org/2735443002
Cr-Commit-Position: refs/heads/master@{#457537}
Committed: https://chromium.googlesource.com/chromium/src/+/6e01aaaf5d8005a96e817d458e6d2c1de43331d6

[falken, 2017-03-07 06:14:39]

Thanks for the patch, Mike!

More detailed comments to come. First some meta stuff:
- Do you know about the CLA steps here?
https://www.chromium.org/developers/contributing-code#TOC-Legal-stuff
(we could talk over email too)

- For the issue description, the oneline summary could be more specific. I am
thinking something like "Upstream service worker navigation preload tests to
WPT". Also since Chromium's SW tests were largely used in the original creation
of the WPT tests, and we've upstreamed some things since then, I'd rather not
say it's the "first commit". Actually I think you can just remove the second
sentence.

- For the bug #, you can use BUG=688116

- I didn't seem to get an email about this review. You may already know this,
but when the review is ready you can go to Publish+Mail Comments -> Publish to
send out the review.

[falken, 2017-03-07 06:25:59]

This looks good, just a nit and a question.

https://codereview.chromium.org/2735443002/diff/1/third_party/WebKit/LayoutTe...
File
third_party/WebKit/LayoutTests/external/wpt/service-workers/service-worker/navigation-preload/resources/chunked-encoding-scope.py
(right):

https://codereview.chromium.org/2735443002/diff/1/third_party/WebKit/LayoutTe...
third_party/WebKit/LayoutTests/external/wpt/service-workers/service-worker/navigation-preload/resources/chunked-encoding-scope.py:9:
response.writer.write_header("Transfer-encoding", "chunked")
nit: Make the double-quoted strings above be single-quotes strings for
consistency with the strings below, or the other way around.

https://codereview.chromium.org/2735443002/diff/1/third_party/WebKit/LayoutTe...
File
third_party/WebKit/LayoutTests/external/wpt/service-workers/service-worker/navigation-preload/resources/request-headers-scope.py
(right):

https://codereview.chromium.org/2735443002/diff/1/third_party/WebKit/LayoutTe...
third_party/WebKit/LayoutTests/external/wpt/service-workers/service-worker/navigation-preload/resources/request-headers-scope.py:7:
normalized[key.upper()] = values[-1]
I am a little confused why values[-1] is used. I get that |headers| is a map
from |key| to a list of |values|. Do we expect |values| to have multiple items?
Why is the last item of the list used?

[mike3, 2017-03-07 16:44:29]

> - Do you know about the CLA steps here?
> https://www.chromium.org/developers/contributing-code#TOC-Legal-stuff

Yes, though I have previously signed with this e-mail address for prior
contributions to the V8 project:

    https://codereview.chromium.org/search?owner=mike%40mikepennisi.com

I visited that page before submitting this patch, and it seemed as though
Chromium uses the same CLA. For me, the signature form is rendered with the
following message:

> It looks like you've already signed this CLA. If you'd like to edit your
> contact information, you may do so below.

Is there some additional step I should take for the Chromium project
specifically?

> - I didn't seem to get an email about this review. You may already know this,
>   but when the review is ready you can go to Publish+Mail Comments -> Publish
>   to send out the review.

Got it. I was thinking that the `R=` line in the commit message would be
sufficient. I'll be sure to use "Publish+Mail Comments" for my future
contributions.

[mike3, 2017-03-07 16:47:04]

Thanks for the review, Matt!

https://codereview.chromium.org/2735443002/diff/1/third_party/WebKit/LayoutTe...
File
third_party/WebKit/LayoutTests/external/wpt/service-workers/service-worker/navigation-preload/resources/chunked-encoding-scope.py
(right):

https://codereview.chromium.org/2735443002/diff/1/third_party/WebKit/LayoutTe...
third_party/WebKit/LayoutTests/external/wpt/service-workers/service-worker/navigation-preload/resources/chunked-encoding-scope.py:9:
response.writer.write_header("Transfer-encoding", "chunked")
On 2017/03/07 06:25:59, falken wrote:
> nit: Make the double-quoted strings above be single-quotes strings for
> consistency with the strings below, or the other way around.

Oh, of course! How sloppy of me.

https://codereview.chromium.org/2735443002/diff/1/third_party/WebKit/LayoutTe...
File
third_party/WebKit/LayoutTests/external/wpt/service-workers/service-worker/navigation-preload/resources/request-headers-scope.py
(right):

https://codereview.chromium.org/2735443002/diff/1/third_party/WebKit/LayoutTe...
third_party/WebKit/LayoutTests/external/wpt/service-workers/service-worker/navigation-preload/resources/request-headers-scope.py:7:
normalized[key.upper()] = values[-1]
On 2017/03/07 06:25:59, falken wrote:
> I am a little confused why values[-1] is used. I get that |headers| is a map
> from |key| to a list of |values|. Do we expect |values| to have multiple
items?
> Why is the last item of the list used?

I was operating under the incorrect assumption that HTTP headers were
interpreted using a "last one wins" heuristic. I was hoping to keep the
particulars of the Python header parsing out of the assertions themselves, but
I suppose that it's unavoidable to have some artifact when translating from
"header fields" to "JSON object". I'll simply return `values` unaltered and
update the assertions to expect single-element array values.

[falken, 2017-03-08 15:28:45]

Sorry, I was out of office today and forgo to set the ooo message. I'll get to
this ASAP tomorrow.

[falken, 2017-03-09 04:07:03]

On 2017/03/07 16:44:29, mike3 wrote:
> > - Do you know about the CLA steps here?
> > https://www.chromium.org/developers/contributing-code#TOC-Legal-stuff
> 
> Yes, though I have previously signed with this e-mail address for prior
> contributions to the V8 project:
> 
>     https://codereview.chromium.org/search?owner=mike%40mikepennisi.com
> 
> I visited that page before submitting this patch, and it seemed as though
> Chromium uses the same CLA. For me, the signature form is rendered with the
> following message:
> 
> > It looks like you've already signed this CLA. If you'd like to edit your
> > contact information, you may do so below.
> 
> Is there some additional step I should take for the Chromium project
> specifically?
> 

Ah thanks. Yep I could verify the CLA for that email address. So all that's
needed is to add yourself to src/AUTHORS in this CL:
https://cs.chromium.org/chromium/src/AUTHORS

[falken, 2017-03-09 04:18:11]

Looking good. FYI the CL description hasn't been altered since the original
review. I think you edited the patch set description (i.e., "Upstream service
worker nav. preload tests to WPT #") where you intended to edit the issue
description (via the Edit Issue link).

https://codereview.chromium.org/2735443002/diff/1/third_party/WebKit/LayoutTe...
File
third_party/WebKit/LayoutTests/external/wpt/service-workers/service-worker/navigation-preload/resources/request-headers-scope.py
(right):

https://codereview.chromium.org/2735443002/diff/1/third_party/WebKit/LayoutTe...
third_party/WebKit/LayoutTests/external/wpt/service-workers/service-worker/navigation-preload/resources/request-headers-scope.py:7:
normalized[key.upper()] = values[-1]
On 2017/03/07 16:47:03, mike3 wrote:
> On 2017/03/07 06:25:59, falken wrote:
> > I am a little confused why values[-1] is used. I get that |headers| is a map
> > from |key| to a list of |values|. Do we expect |values| to have multiple
> items?
> > Why is the last item of the list used?
> 
> I was operating under the incorrect assumption that HTTP headers were
> interpreted using a "last one wins" heuristic. I was hoping to keep the
> particulars of the Python header parsing out of the assertions themselves, but
> I suppose that it's unavoidable to have some artifact when translating from
> "header fields" to "JSON object". I'll simply return `values` unaltered and
> update the assertions to expect single-element array values.

Makes sense, thanks for making this rigorous.

https://codereview.chromium.org/2735443002/diff/20001/third_party/WebKit/Layo...
File
third_party/WebKit/LayoutTests/external/wpt/service-workers/service-worker/navigation-preload/request-headers.html
(right):

https://codereview.chromium.org/2735443002/diff/20001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/external/wpt/service-workers/service-worker/navigation-preload/request-headers.html:22:
'The Navigation Preload request must specify exactly a ' +
Should this description say "exactly one"? But the assert doesn't seem to reject
the more than one case, so maybe the description should just say one exists, and
the next assert would catch the >= 1 case.

https://codereview.chromium.org/2735443002/diff/20001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/external/wpt/service-workers/service-worker/navigation-preload/request-headers.html:36:
'The header of Navigation Preload request must have ' +
nit: This should probably say "correct" to match the earlier assert for the
other header, and to distinguish itself from the previous assert.

[mike3, 2017-03-09 16:05:09]

> Ah thanks. Yep I could verify the CLA for that email address. So all that's
> needed is to add yourself to src/AUTHORS in this CL:
> https://cs.chromium.org/chromium/src/AUTHORS

Got it!

> Looking good. FYI the CL description hasn't been altered since the original
> review. I think you edited the patch set description (i.e., "Upstream service
> worker nav. preload tests to WPT #") where you intended to edit the issue
> description (via the Edit Issue link).

You are correct. I'll update the issue description presently.

Sorry to keep getting tripped up with these minor mistakes! Hopefully things
go smoother with my future patches

https://codereview.chromium.org/2735443002/diff/20001/third_party/WebKit/Layo...
File
third_party/WebKit/LayoutTests/external/wpt/service-workers/service-worker/navigation-preload/request-headers.html
(right):

https://codereview.chromium.org/2735443002/diff/20001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/external/wpt/service-workers/service-worker/navigation-preload/request-headers.html:22:
'The Navigation Preload request must specify exactly a ' +
On 2017/03/09 04:18:10, falken wrote:
> Should this description say "exactly one"? But the assert doesn't seem to
reject
> the more than one case, so maybe the description should just say one exists,
and
> the next assert would catch the >= 1 case.

Yes, I went from "exactly one" to "exactly a", but it ought to read simply, "a".

https://codereview.chromium.org/2735443002/diff/20001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/external/wpt/service-workers/service-worker/navigation-preload/request-headers.html:36:
'The header of Navigation Preload request must have ' +
On 2017/03/09 04:18:10, falken wrote:
> nit: This should probably say "correct" to match the earlier assert for the
> other header, and to distinguish itself from the previous assert.

Definitely. This message could use a little grammatical tweaking beyond that.

[mike3, 2017-03-09 16:05:56]

Description was changed from

==========
Refactor ServiceWorker tests for inclusion in WPT

This is the first commit in an ongoing effort to share Chromium's
ServiceWorker tests with other projects by submitting them to the Web
Platform Tests.

BUG=
R=falken@chromium.org
==========

to

==========
Upstream service worker nav. preload tests to WPT

BUG=688116
R=falken@chromium.org
==========

[falken, 2017-03-10 02:09:20]

Thanks Mike. The CL looks good, and I finally patched in your CL and ran the
tests. I think we have some more excitement here. First there are some things I
overlooked earlier:

- The tests need the *.https.html filename so they run over https. Service
worker requires https.
- The navigation preload feature is not yet enabled in Chrome. So we need a
"virtual test suite" that runs with the feature enabled. For the
https/*/navigation-preload tests, we accomplish this by:
In TestExpectations:
# Requires ServiceWorkerNavigationPreload feature enabled. Run under
# virtual/service-worker-navigation-preload only.
crbug.com/649558 http/tests/serviceworker/navigation-preload/ [ Skip ]

In VirtualTestSuites
  {
    "prefix": "service-worker-navigation-preload",
    "base": "http/tests/serviceworker",
    "args": ["--enable-features=ServiceWorkerNavigationPreload"]
  },

We'll need something similar for NavPreload.

But the biggest mystery is even when serving over https, I'm getting a weird
cross-domain error when running the test locally:

FAIL Navigation Preload with broken chunked encoding must fail. promise_test:
Unhandled rejection with value: object "SecurityError: Failed to read the
'contentDocument' property from 'HTMLIFrameElement': Blocked a frame with origin
"https://web-platform.test:8444" from accessing a cross-origin frame."

This is unexpected because we don't create a cross-origin iframe in the test.
I'm digging into this mystery now.

[falken, 2017-03-10 02:27:15]

On 2017/03/10 02:09:20, falken wrote:
> Thanks Mike. The CL looks good, and I finally patched in your CL and ran the
> tests. I think we have some more excitement here. First there are some things
I
> overlooked earlier:
> 
> - The tests need the *.https.html filename so they run over https. Service
> worker requires https.
> - The navigation preload feature is not yet enabled in Chrome. So we need a
> "virtual test suite" that runs with the feature enabled. For the
> https/*/navigation-preload tests, we accomplish this by:
> In TestExpectations:
> # Requires ServiceWorkerNavigationPreload feature enabled. Run under
> # virtual/service-worker-navigation-preload only.
> crbug.com/649558 http/tests/serviceworker/navigation-preload/ [ Skip ]
> 
> In VirtualTestSuites
>   {
>     "prefix": "service-worker-navigation-preload",
>     "base": "http/tests/serviceworker",
>     "args": ["--enable-features=ServiceWorkerNavigationPreload"]
>   },
> 
> We'll need something similar for NavPreload.
> 
> But the biggest mystery is even when serving over https, I'm getting a weird
> cross-domain error when running the test locally:
> 
> FAIL Navigation Preload with broken chunked encoding must fail. promise_test:
> Unhandled rejection with value: object "SecurityError: Failed to read the
> 'contentDocument' property from 'HTMLIFrameElement': Blocked a frame with
origin
> "https://web-platform.test:8444" from accessing a cross-origin frame."
> 
> This is unexpected because we don't create a cross-origin iframe in the test.
> I'm digging into this mystery now.

I think I see what's going on. Since NavPreload is not enabled by default, the
service worker fails and ultimately a network error occurs when loading the
iframe. The network error apparently causes Chrome to treat it as a cross-origin
iframe. So if we make the virtual test suite, the tests should pass.

[falken, 2017-03-10 03:40:30]

Additionally we must tell the test runner to use wptserve on the virtual test
suite (see https://bugs.chromium.org/p/chromium/issues/detail?id=694910)

I confirmed with the below changes and renaming the tests to https.html, things
seem to work:

--- a/third_party/WebKit/LayoutTests/VirtualTestSuites
+++ b/third_party/WebKit/LayoutTests/VirtualTestSuites
@@ -321,6 +321,11 @@
     "args": ["--enable-features=ServiceWorkerNavigationPreload"]
   },
   {
+    "prefix": "service-worker-navigation-preload-wpt",
+    "base": "external/wpt/service-workers/service-worker/navigation-preload",
+    "args": ["--enable-features=ServiceWorkerNavigationPreload"]
+  },
+  {
     "prefix": "service-worker-navigation-preload-disabled",
     "base": "http/tests/serviceworker/chromium",
     "args": ["--disable-features=ServiceWorkerNavigationPreload"]
diff --git a/third_party/WebKit/Tools/Scripts/webkitpy/layout_tests/port/base.py
b/third_party/WebKit/Tools/Scripts/webkitpy/layout_tests/port/base.py
index 177028ada7cd..b3690c5e2218 100644
--- a/third_party/WebKit/Tools/Scripts/webkitpy/layout_tests/port/base.py
+++ b/third_party/WebKit/Tools/Scripts/webkitpy/layout_tests/port/base.py
@@ -1148,7 +1148,7 @@ class Port(object):
     @staticmethod
     def is_wptserve_test(test):
         """Whether wptserve should be used for a given test if enabled."""
-        return test.startswith("external/wpt/")
+        return 'external/wpt/' in test

     def should_use_wptserve(self, test):

You'd run the tests using:
$ run-webkit-tests
virtual/service-worker-navigation-preload-wpt/external/wpt/service-workers/service-worker/navigation-preload/

[mike3, 2017-03-11 00:46:14]

I've made the changes you requested, but I have not been able to verify them
locally. After applying your patch, the command you shared continues to report,
"No tests to run." Some thoughts on that:

- It seems as though I may need to introduce additional files to the
  `third_party/WebKit/LayoutTests/virtual/` directory. The linter complains
  about a missing `README.txt` file, but are there any other files I should be
  introducing there?
- Does the current working directory matter when invoking `run-webkit-tests`?
- I have not yet built Chromium locally. (For context: I was previously
  validating my work by running `run-blink-wptserve` and manually loading tests
  in my system's installed version of Google Chrome. This is why I'm only just
  now learning about the file name restriction and feature flag requirement.)

I am having trouble building Chromium, though. I plan to continue to work at
that, but in the mean time, I've submitted a new unverified patch that includes
the changes you have requested.

Thanks for your patience through all this!

[falken, 2017-03-11 02:07:36]

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

[commit-bot: I haz the power, 2017-03-11 02:07:47]

Dry run: 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, 2017-03-11 04:27:09]

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

[commit-bot: I haz the power, 2017-03-11 04:27:09]

Dry run: This issue passed the CQ dry run.

[falken, 2017-03-13 06:46:25]

lgtm 

I can patch in your change locally and the tests are run. So it seems working.

$ third_party/WebKit/Tools/Scripts/run-webkit-tests --target=Default
--no-retry-failures
virtual/service-worker-navigation-preload-wpt/external/wpt/service-workers/service-worker/navigation-preload/

Also the trybots are running the tests.

[falken, 2017-03-13 06:47:00]

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

[falken, 2017-03-13 06:47:01]

tkent: Could you review
	third_party/WebKit/Tools/Scripts/webkitpy/layout_tests/port/base.py?

[tkent, 2017-03-13 06:50:32]

https://codereview.chromium.org/2735443002/diff/60001/third_party/WebKit/Tool...
File third_party/WebKit/Tools/Scripts/webkitpy/layout_tests/port/base.py
(right):

https://codereview.chromium.org/2735443002/diff/60001/third_party/WebKit/Tool...
third_party/WebKit/Tools/Scripts/webkitpy/layout_tests/port/base.py:1154: return
"external/wpt/" in test
Please add test to base_unittest.py

[qyearsley, 2017-03-14 19:46:11]

https://codereview.chromium.org/2735443002/diff/60001/third_party/WebKit/Tool...
File third_party/WebKit/Tools/Scripts/webkitpy/layout_tests/port/base.py
(right):

https://codereview.chromium.org/2735443002/diff/60001/third_party/WebKit/Tool...
third_party/WebKit/Tools/Scripts/webkitpy/layout_tests/port/base.py:1154: return
"external/wpt/" in test
On 2017/03/13 at 06:50:32, tkent wrote:
> Please add test to base_unittest.py

Could potentially note that we're looking for this substring anywhere in order
to include virtual tests.

If we want to be more conservative, we could do something like:

return re.match(r'^(virtual/[^/]+/)?external/wpt/.*$')

But this may be more complex than necessary, and we'd want unit tests to make
sure the regular expression is right...

[mike3, 2017-03-14 22:12:05]

tkent and qyearsley: thanks for the input! I'm working on this now.

falken: I haven't been able to implement tkent's request because I'm still
troubleshooting my Chromium installation.

Yesterday (with assistance from Torne on IRC), I was able to build the project
and run the browser. I couldn't run the tests, though. Today (following advice
from qyearsley on IRC), I learned how to build the WebKit tests. Unfortunately,
the command you've shared consistently reports an error related to
`content_shell` [1]:

>     content_shell took too long to startup.

Mek on IRC suggested that the problem may be related to
https://bugs.chromium.org/p/chromium/issues/detail?id=697954, and while I can't
view that issue, he shared a workaround being discussed there. Applying that
change (see [2]) doesn't resolve my problem, but I haven't thrown in the towel
yet! Just wanted you to know that I'm still on the case, despite the lack of
new code.

[1] https://gist.github.com/jugglinmike/dd60b4d2c0ce209db58fa28bd77628e6
[2]
    $ git diff
    diff --git
a/third_party/WebKit/Tools/Scripts/webkitpy/layout_tests/port/linux.py
b/third_party/WebKit/Tools/Scripts/webkitpy/layout_tests/port/linux.py
    index 60a6863..4087ef8 100644
    --- a/third_party/WebKit/Tools/Scripts/webkitpy/layout_tests/port/linux.py
    +++ b/third_party/WebKit/Tools/Scripts/webkitpy/layout_tests/port/linux.py
    @@ -104,11 +104,17 @@ class LinuxPort(base.Port):

         def setup_test_run(self):
             super(LinuxPort, self).setup_test_run()
    -        self._setup_dummy_home_dir()
    +        # The following line has been disabled as a temporary workaround
for
    +        # https://bugs.chromium.org/p/chromium/issues/detail?id=697954
    +        # --mike
    +        #self._setup_dummy_home_dir()

         def clean_up_test_run(self):
             super(LinuxPort, self).clean_up_test_run()
    -        self._clean_up_dummy_home_dir()
    +        # The following line has been disabled as a temporary workaround
for
    +        # https://bugs.chromium.org/p/chromium/issues/detail?id=697954
    +        # --mike
    +        #self._clean_up_dummy_home_dir()

         #
         # PROTECTED METHODS

[falken, 2017-03-15 02:03:45]

Hi Mike, sorry for these hiccups.

It looks like you can edit base_unittest.py and then run the unit test without
building content_shell, via:
$ third_party/WebKit/Tools/Scripts/test-webkitpy

So for this patch you don't need to block on getting run-webkit-tests working,
since the try bots are happy (it'd be useful for future work though).

[mike3, 2017-03-15 15:23:34]

> So for this patch you don't need to block on getting run-webkit-tests working

Right you are! I've added some assetions and incorporated qyearsley's feedback
as well. Although at first I thought it might be more complex than necessary, I
think it makes the code more self-documenting because it better communicates
our intentions.

[tkent, 2017-03-15 22:46:00]

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

[tkent, 2017-03-15 22:46:05]

lgtm

[commit-bot: I haz the power, 2017-03-15 22:46:24]

Dry run: 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, 2017-03-15 22:49:29]

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

[commit-bot: I haz the power, 2017-03-15 22:49:31]

Dry run: Try jobs failed on following builders:
  ios-simulator on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-simulator/bui...)
  ios-simulator-xcode-clang on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-simulator-xco...)

[falken, 2017-03-16 01:40:09]

We're almost there :)

The patch is now failing to apply. You can run "git rebase-update" and fix
conflicts, then reupload. It looks like base.py was recently reformatted.

[mike3, 2017-03-16 19:18:38]

On 2017/03/16 01:40:09, falken wrote:
> We're almost there :)
> 
> The patch is now failing to apply. You can run "git rebase-update" and fix
> conflicts, then reupload. It looks like base.py was recently reformatted.

All set!

[mike3, 2017-03-16 19:19:23]

The CQ bit was checked by mike@mikepennisi.com

[mike3, 2017-03-16 19:19:23]

The patchset sent to the CQ was uploaded after l-g-t-m from falken@chromium.org,
tkent@chromium.org
Link to the patchset: https://codereview.chromium.org/2735443002/#ps100001
(title: "Upstream service worker nav. preload tests to WPT")

[commit-bot: I haz the power, 2017-03-16 19:20:13]

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, 2017-03-16 20:37:35]

CQ is committing da patch.

Bot data: {"patchset_id": 100001, "attempt_start_ts": 1489691963173670,
"parent_rev": "92c1a4cf87397d9a63c6e1bc0bb6ecc141a0979c", "commit_rev":
"6e01aaaf5d8005a96e817d458e6d2c1de43331d6"}

[commit-bot: I haz the power, 2017-03-16 20:38:21]

Description was changed from

==========
Upstream service worker nav. preload tests to WPT

BUG=688116
R=falken@chromium.org
==========

to

==========
Upstream service worker nav. preload tests to WPT

BUG=688116
R=falken@chromium.org

Review-Url: https://codereview.chromium.org/2735443002
Cr-Commit-Position: refs/heads/master@{#457537}
Committed:
https://chromium.googlesource.com/chromium/src/+/6e01aaaf5d8005a96e817d458e6d...
==========

[commit-bot: I haz the power, 2017-03-16 20:38:22]

Committed patchset #6 (id:100001) as
https://chromium.googlesource.com/chromium/src/+/6e01aaaf5d8005a96e817d458e6d...

[mike3, 2017-03-16 20:40:02]

On 2017/03/16 20:38:22, commit-bot: I haz the power wrote:
> Committed patchset #6 (id:100001) as
>
https://chromium.googlesource.com/chromium/src/+/6e01aaaf5d8005a96e817d458e6d...

Thanks falken, tkent, and qyearsley!

[falken, 2017-03-17 01:06:38]

On 2017/03/16 20:40:02, mike3 wrote:
> On 2017/03/16 20:38:22, commit-bot: I haz the power wrote:
> > Committed patchset #6 (id:100001) as
> >
>
https://chromium.googlesource.com/chromium/src/+/6e01aaaf5d8005a96e817d458e6d...
> 
> Thanks falken, tkent, and qyearsley!

Nice patch! Thanks for sticking with this.