fixed encodedBodySize/decodedBodySize/name/initiatorType for nav timing 2

fixed encodedBodySize/decodedBodySize/initiatorType for nav timing 2. Report initiatorType as "navigation" instead of an empty string.

BUG=675044, 675042
Review-Url: https://codereview.chromium.org/2582863002
Cr-Commit-Position: refs/heads/master@{#443445}
Committed: https://chromium.googlesource.com/chromium/src/+/59250b64593759462cdefbf4f411f1cca6e0c696

[sunjian, 2016-12-16 21:48:44]

Description was changed from

==========
fixed encodedBodySize/decodedBodySize/name/initiatorType for nav timing 2

BUG=
==========

to

==========
fixed encodedBodySize/decodedBodySize/name/initiatorType for nav timing 2

BUG=675044,675042,675039
==========

[sunjian, 2016-12-16 23:49:00]

Patchset #1 (id:1) has been deleted

[sunjian, 2016-12-16 23:49:19]

Description was changed from

==========
fixed encodedBodySize/decodedBodySize/name/initiatorType for nav timing 2

BUG=675044,675042,675039
==========

to

==========
fixed encodedBodySize/decodedBodySize/initiatorType for nav timing 2

BUG=675044,675042
==========

[sunjian, 2016-12-19 19:19:30]

sunjian@chromium.org changed reviewers:
+ panicker@chromium.org

[Yoav Weiss, 2016-12-19 21:13:50]

On 2016/12/19 19:19:31, sunjian wrote:

Can you add tests for this fix? (Or is it tested by the WPT ones?)

[panicker, 2016-12-19 21:36:57]

panicker@chromium.org changed reviewers:
+ yoav@yoav.ws

[sunjian, 2016-12-19 21:38:08]

On 2016/12/19 21:13:50, Yoav Weiss wrote:
> On 2016/12/19 19:19:31, sunjian wrote:
> 
> Can you add tests for this fix? (Or is it tested by the WPT ones?)

Yes, it will be covered in wpt.

[panicker, 2016-12-19 21:42:00]

Re: testing: let's add an item to the test plan doc, and then send separate
patch for WPT tests.

https://codereview.chromium.org/2582863002/diff/20001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/timing/PerformanceNavigationTiming.cpp
(right):

https://codereview.chromium.org/2582863002/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/timing/PerformanceNavigationTiming.cpp:48: :
PerformanceResourceTiming("navigation",
mention this change in CL description

[sunjian, 2016-12-19 22:29:10]

Description was changed from

==========
fixed encodedBodySize/decodedBodySize/initiatorType for nav timing 2

BUG=675044,675042
==========

to

==========
fixed encodedBodySize/decodedBodySize/initiatorType for nav timing 2. Report
initiatorType as "navigation" instead of an empty string.

BUG=675044,675042
==========

[Yoav Weiss, 2016-12-20 10:00:24]

On 2016/12/19 21:42:00, panicker wrote:
> Re: testing: let's add an item to the test plan doc, and then send separate
> patch for WPT tests.

Talking to foolip@ on IRC, looks like we have a couple of options:
1) Land the tests in WPT, import them, then land this code.
2) Try out a new process added in crbug.com/657117 which enables us to land
tests directly in LayoutTests/imported/wpt/ and have them exported
automatically. This process is fairly new so (to quote foolip@) "there is one
caveat, and that's that you still have to update MANIFEST.json manually, and for
that you need a checkout of upstream web-platform-tests to get the manifest
script"

[jeffcarp, 2016-12-21 00:23:20]

On 2016/12/20 at 10:00:24, yoav wrote:
> On 2016/12/19 21:42:00, panicker wrote:
> > Re: testing: let's add an item to the test plan doc, and then send separate
> > patch for WPT tests.
> 
> Talking to foolip@ on IRC, looks like we have a couple of options:
> 1) Land the tests in WPT, import them, then land this code.
> 2) Try out a new process added in crbug.com/657117 which enables us to land
tests directly in LayoutTests/imported/wpt/ and have them exported
automatically. This process is fairly new so (to quote foolip@) "there is one
caveat, and that's that you still have to update MANIFEST.json manually, and for
that you need a checkout of upstream web-platform-tests to get the manifest
script"

If you want to try #2, just CC me on any exportable CLs (i.e. with changes in
LayoutTests/imported/wpt/) and I'll upstream them after they land.

[panickercorp, 2016-12-21 01:38:04]

On 2016/12/21 00:23:20, jeffcarp wrote:
> On 2016/12/20 at 10:00:24, yoav wrote:
> > On 2016/12/19 21:42:00, panicker wrote:
> > > Re: testing: let's add an item to the test plan doc, and then send
separate
> > > patch for WPT tests.
> > 
> > Talking to foolip@ on IRC, looks like we have a couple of options:
> > 1) Land the tests in WPT, import them, then land this code.
> > 2) Try out a new process added in crbug.com/657117 which enables us to land
> tests directly in LayoutTests/imported/wpt/ and have them exported
> automatically. This process is fairly new so (to quote foolip@) "there is one
> caveat, and that's that you still have to update MANIFEST.json manually, and
for
> that you need a checkout of upstream web-platform-tests to get the manifest
> script"
> 
> If you want to try #2, just CC me on any exportable CLs (i.e. with changes in
> LayoutTests/imported/wpt/) and I'll upstream them after they land.

Thanks folks.
We went with #1 thinking it might be simpler but seems like that's no longer
true with recent process improvements (great!)
AFAIK the only thing we are blocked on right now (with #1) is getting
toddreifsteck to review the tests, I suppose #2 doesn't entail that? :)


Separately, Yoav - I'm not sure why landing this (strictly) bug fix CL needs to
block on the WPT test, this CL has been tested manually and with the WPT test.
Could you elaborate? :)

[Yoav Weiss, 2016-12-21 12:53:09]

On 2016/12/21 01:38:04, panickercorp wrote:
> On 2016/12/21 00:23:20, jeffcarp wrote:
> > On 2016/12/20 at 10:00:24, yoav wrote:
> > > On 2016/12/19 21:42:00, panicker wrote:
> > > > Re: testing: let's add an item to the test plan doc, and then send
> separate
> > > > patch for WPT tests.
> > > 
> > > Talking to foolip@ on IRC, looks like we have a couple of options:
> > > 1) Land the tests in WPT, import them, then land this code.
> > > 2) Try out a new process added in crbug.com/657117 which enables us to
land
> > tests directly in LayoutTests/imported/wpt/ and have them exported
> > automatically. This process is fairly new so (to quote foolip@) "there is
one
> > caveat, and that's that you still have to update MANIFEST.json manually, and
> for
> > that you need a checkout of upstream web-platform-tests to get the manifest
> > script"
> > 
> > If you want to try #2, just CC me on any exportable CLs (i.e. with changes
in
> > LayoutTests/imported/wpt/) and I'll upstream them after they land.
> 
> Thanks folks.
> We went with #1 thinking it might be simpler but seems like that's no longer
> true with recent process improvements (great!)
> AFAIK the only thing we are blocked on right now (with #1) is getting
> toddreifsteck to review the tests, I suppose #2 doesn't entail that? :)
> 
> 
> Separately, Yoav - I'm not sure why landing this (strictly) bug fix CL needs
to
> block on the WPT test, this CL has been tested manually and with the WPT test.
> Could you elaborate? :)

It doesn't necessarily have to block on the WPT tests (e.g. we could land the
same test here and remove it once WPT lands, or use the new export workflow).
At the same time, any functional change requires test coverage that exercises
that change and makes sure it doesn't regress.
esprehn@ wrote more about the reasoning for that in
https://groups.google.com/a/chromium.org/d/msg/chromium-dev/Z4rUnmyrsJI/TTG6P...

[panicker, 2016-12-21 18:09:56]

On 2016/12/21 12:53:09, Yoav Weiss wrote:
> On 2016/12/21 01:38:04, panickercorp wrote:
> > On 2016/12/21 00:23:20, jeffcarp wrote:
> > > On 2016/12/20 at 10:00:24, yoav wrote:
> > > > On 2016/12/19 21:42:00, panicker wrote:
> > > > > Re: testing: let's add an item to the test plan doc, and then send
> > separate
> > > > > patch for WPT tests.
> > > > 
> > > > Talking to foolip@ on IRC, looks like we have a couple of options:
> > > > 1) Land the tests in WPT, import them, then land this code.
> > > > 2) Try out a new process added in crbug.com/657117 which enables us to
> land
> > > tests directly in LayoutTests/imported/wpt/ and have them exported
> > > automatically. This process is fairly new so (to quote foolip@) "there is
> one
> > > caveat, and that's that you still have to update MANIFEST.json manually,
and
> > for
> > > that you need a checkout of upstream web-platform-tests to get the
manifest
> > > script"
> > > 
> > > If you want to try #2, just CC me on any exportable CLs (i.e. with changes
> in
> > > LayoutTests/imported/wpt/) and I'll upstream them after they land.
> > 
> > Thanks folks.
> > We went with #1 thinking it might be simpler but seems like that's no longer
> > true with recent process improvements (great!)
> > AFAIK the only thing we are blocked on right now (with #1) is getting
> > toddreifsteck to review the tests, I suppose #2 doesn't entail that? :)
> > 
> > 
> > Separately, Yoav - I'm not sure why landing this (strictly) bug fix CL needs
> to
> > block on the WPT test, this CL has been tested manually and with the WPT
test.
> > Could you elaborate? :)
> 
> It doesn't necessarily have to block on the WPT tests (e.g. we could land the
> same test here and remove it once WPT lands, or use the new export workflow).
> At the same time, any functional change requires test coverage that exercises
> that change and makes sure it doesn't regress.
> esprehn@ wrote more about the reasoning for that in
>
https://groups.google.com/a/chromium.org/d/msg/chromium-dev/Z4rUnmyrsJI/TTG6P...

Let's pick this up when we get back (Jian is OOO, and I will be too after
today).
I expect WPT tests to have been merged by then and we can import them.

In general going forward, I think we should go with your suggested approach #2
to land the tests in LayoutTests first (thanks for the tip!)

[panicker, 2016-12-21 18:15:58]

On 2016/12/21 18:09:56, panicker wrote:
> On 2016/12/21 12:53:09, Yoav Weiss wrote:
> > On 2016/12/21 01:38:04, panickercorp wrote:
> > > On 2016/12/21 00:23:20, jeffcarp wrote:
> > > > On 2016/12/20 at 10:00:24, yoav wrote:
> > > > > On 2016/12/19 21:42:00, panicker wrote:
> > > > > > Re: testing: let's add an item to the test plan doc, and then send
> > > separate
> > > > > > patch for WPT tests.
> > > > > 
> > > > > Talking to foolip@ on IRC, looks like we have a couple of options:
> > > > > 1) Land the tests in WPT, import them, then land this code.
> > > > > 2) Try out a new process added in crbug.com/657117 which enables us to
> > land
> > > > tests directly in LayoutTests/imported/wpt/ and have them exported
> > > > automatically. This process is fairly new so (to quote foolip@) "there
is
> > one
> > > > caveat, and that's that you still have to update MANIFEST.json manually,
> and
> > > for
> > > > that you need a checkout of upstream web-platform-tests to get the
> manifest
> > > > script"
> > > > 
> > > > If you want to try #2, just CC me on any exportable CLs (i.e. with
changes
> > in
> > > > LayoutTests/imported/wpt/) and I'll upstream them after they land.
> > > 
> > > Thanks folks.
> > > We went with #1 thinking it might be simpler but seems like that's no
longer
> > > true with recent process improvements (great!)
> > > AFAIK the only thing we are blocked on right now (with #1) is getting
> > > toddreifsteck to review the tests, I suppose #2 doesn't entail that? :)
> > > 
> > > 
> > > Separately, Yoav - I'm not sure why landing this (strictly) bug fix CL
needs
> > to
> > > block on the WPT test, this CL has been tested manually and with the WPT
> test.
> > > Could you elaborate? :)
> > 
> > It doesn't necessarily have to block on the WPT tests (e.g. we could land
the
> > same test here and remove it once WPT lands, or use the new export
workflow).
> > At the same time, any functional change requires test coverage that
exercises
> > that change and makes sure it doesn't regress.
> > esprehn@ wrote more about the reasoning for that in
> >
>
https://groups.google.com/a/chromium.org/d/msg/chromium-dev/Z4rUnmyrsJI/TTG6P...
> 
> Let's pick this up when we get back (Jian is OOO, and I will be too after
> today).
> I expect WPT tests to have been merged by then and we can import them.
> 
> In general going forward, I think we should go with your suggested approach #2
> to land the tests in LayoutTests first (thanks for the tip!)

As an aside I read Elliot's post and we are in conflict with the suggestion (the
tests are already written):
"Any change to a web API should either change tests directly or link to the
tests in the commit description. If your feature has tests outside the repro,
like webgl, then you should make sure to follow up on your patch with a link to
the tests in the code review ..."

[panicker, 2016-12-21 18:16:25]

On 2016/12/21 18:15:58, panicker wrote:
> On 2016/12/21 18:09:56, panicker wrote:
> > On 2016/12/21 12:53:09, Yoav Weiss wrote:
> > > On 2016/12/21 01:38:04, panickercorp wrote:
> > > > On 2016/12/21 00:23:20, jeffcarp wrote:
> > > > > On 2016/12/20 at 10:00:24, yoav wrote:
> > > > > > On 2016/12/19 21:42:00, panicker wrote:
> > > > > > > Re: testing: let's add an item to the test plan doc, and then send
> > > > separate
> > > > > > > patch for WPT tests.
> > > > > > 
> > > > > > Talking to foolip@ on IRC, looks like we have a couple of options:
> > > > > > 1) Land the tests in WPT, import them, then land this code.
> > > > > > 2) Try out a new process added in crbug.com/657117 which enables us
to
> > > land
> > > > > tests directly in LayoutTests/imported/wpt/ and have them exported
> > > > > automatically. This process is fairly new so (to quote foolip@) "there
> is
> > > one
> > > > > caveat, and that's that you still have to update MANIFEST.json
manually,
> > and
> > > > for
> > > > > that you need a checkout of upstream web-platform-tests to get the
> > manifest
> > > > > script"
> > > > > 
> > > > > If you want to try #2, just CC me on any exportable CLs (i.e. with
> changes
> > > in
> > > > > LayoutTests/imported/wpt/) and I'll upstream them after they land.
> > > > 
> > > > Thanks folks.
> > > > We went with #1 thinking it might be simpler but seems like that's no
> longer
> > > > true with recent process improvements (great!)
> > > > AFAIK the only thing we are blocked on right now (with #1) is getting
> > > > toddreifsteck to review the tests, I suppose #2 doesn't entail that? :)
> > > > 
> > > > 
> > > > Separately, Yoav - I'm not sure why landing this (strictly) bug fix CL
> needs
> > > to
> > > > block on the WPT test, this CL has been tested manually and with the WPT
> > test.
> > > > Could you elaborate? :)
> > > 
> > > It doesn't necessarily have to block on the WPT tests (e.g. we could land
> the
> > > same test here and remove it once WPT lands, or use the new export
> workflow).
> > > At the same time, any functional change requires test coverage that
> exercises
> > > that change and makes sure it doesn't regress.
> > > esprehn@ wrote more about the reasoning for that in
> > >
> >
>
https://groups.google.com/a/chromium.org/d/msg/chromium-dev/Z4rUnmyrsJI/TTG6P...
> > 
> > Let's pick this up when we get back (Jian is OOO, and I will be too after
> > today).
> > I expect WPT tests to have been merged by then and we can import them.
> > 
> > In general going forward, I think we should go with your suggested approach
#2
> > to land the tests in LayoutTests first (thanks for the tip!)
> 
> As an aside I read Elliot's post and we are in conflict with the suggestion
(the
*not* in conflict
> tests are already written):
> "Any change to a web API should either change tests directly or link to the
> tests in the commit description. If your feature has tests outside the repro,
> like webgl, then you should make sure to follow up on your patch with a link
to
> the tests in the code review ..."

[Yoav Weiss, 2016-12-22 09:41:34]

On 2016/12/21 18:16:25, panicker wrote:
> On 2016/12/21 18:15:58, panicker wrote:
> > On 2016/12/21 18:09:56, panicker wrote:
> > > On 2016/12/21 12:53:09, Yoav Weiss wrote:
> > > > On 2016/12/21 01:38:04, panickercorp wrote:
> > > > > On 2016/12/21 00:23:20, jeffcarp wrote:
> > > > > > On 2016/12/20 at 10:00:24, yoav wrote:
> > > > > > > On 2016/12/19 21:42:00, panicker wrote:
> > > > > > > > Re: testing: let's add an item to the test plan doc, and then
send
> > > > > separate
> > > > > > > > patch for WPT tests.
> > > > > > > 
> > > > > > > Talking to foolip@ on IRC, looks like we have a couple of options:
> > > > > > > 1) Land the tests in WPT, import them, then land this code.
> > > > > > > 2) Try out a new process added in crbug.com/657117 which enables
us
> to
> > > > land
> > > > > > tests directly in LayoutTests/imported/wpt/ and have them exported
> > > > > > automatically. This process is fairly new so (to quote foolip@)
"there
> > is
> > > > one
> > > > > > caveat, and that's that you still have to update MANIFEST.json
> manually,
> > > and
> > > > > for
> > > > > > that you need a checkout of upstream web-platform-tests to get the
> > > manifest
> > > > > > script"
> > > > > > 
> > > > > > If you want to try #2, just CC me on any exportable CLs (i.e. with
> > changes
> > > > in
> > > > > > LayoutTests/imported/wpt/) and I'll upstream them after they land.
> > > > > 
> > > > > Thanks folks.
> > > > > We went with #1 thinking it might be simpler but seems like that's no
> > longer
> > > > > true with recent process improvements (great!)
> > > > > AFAIK the only thing we are blocked on right now (with #1) is getting
> > > > > toddreifsteck to review the tests, I suppose #2 doesn't entail that?
:)
> > > > > 
> > > > > 
> > > > > Separately, Yoav - I'm not sure why landing this (strictly) bug fix CL
> > needs
> > > > to
> > > > > block on the WPT test, this CL has been tested manually and with the
WPT
> > > test.
> > > > > Could you elaborate? :)
> > > > 
> > > > It doesn't necessarily have to block on the WPT tests (e.g. we could
land
> > the
> > > > same test here and remove it once WPT lands, or use the new export
> > workflow).
> > > > At the same time, any functional change requires test coverage that
> > exercises
> > > > that change and makes sure it doesn't regress.
> > > > esprehn@ wrote more about the reasoning for that in
> > > >
> > >
> >
>
https://groups.google.com/a/chromium.org/d/msg/chromium-dev/Z4rUnmyrsJI/TTG6P...
> > > 
> > > Let's pick this up when we get back (Jian is OOO, and I will be too after
> > > today).
> > > I expect WPT tests to have been merged by then and we can import them.
> > > 
> > > In general going forward, I think we should go with your suggested
approach
> #2
> > > to land the tests in LayoutTests first (thanks for the tip!)
> > 
> > As an aside I read Elliot's post and we are in conflict with the suggestion
> (the
> *not* in conflict
> > tests are already written):
> > "Any change to a web API should either change tests directly or link to the
> > tests in the commit description. If your feature has tests outside the
repro,
> > like webgl, then you should make sure to follow up on your patch with a link
> to
> > the tests in the code review ..."

Apologies if I came across as overly strict. I'm just trying to verify that
tests are landing with code changes.
I'll ask for further guidance on this subject.

[panicker, 2017-01-03 21:13:54]

LGTM.
Yoav - the web-platform-tests have landed. PTAL.

[Yoav Weiss, 2017-01-04 06:07:31]

They have indeed landed, but not imported.
I suspect that even if they would be imported, they will not successfully run as
simple tests (I think at least most of them need to be served as wptserve tests,
and therefore block on
https://bugs.chromium.org/p/chromium/issues/detail?id=669802).

I think we should manually import the tests into http/tests/w3c/approved until
the underlying issues are resolved and they are properly imported through the
regular process.
sunjian@ / panicker@ - can one of you take on the manual import?

Adding qyearsley@ for comments on why they are not currently imported.

[qyearsley, 2017-01-04 18:59:28]

On 2017/01/04 at 06:07:31, yoav wrote:
> They have indeed landed, but not imported.
> I suspect that even if they would be imported, they will not successfully run
as simple tests (I think at least most of them need to be served as wptserve
tests, and therefore block on
https://bugs.chromium.org/p/chromium/issues/detail?id=669802).
> 
> I think we should manually import the tests into http/tests/w3c/approved until
the underlying issues are resolved and they are properly imported through the
regular process.
> sunjian@ / panicker@ - can one of you take on the manual import?
> 
> Adding qyearsley@ for comments on why they are not currently imported.

Not currently imported because the auto import job hasn't succeeded since Dec 25
(https://build.chromium.org/p/chromium.infra.cron/builders/w3c-test-autoroller)
-- current problem is http://crbug.com/678077.

The documentation for manual import is still at
https://www.chromium.org/blink/importing-the-w3c-tests#TOC-Manually-Importing...
-- although currently that will fail :-/ I really want to fix this issue and get
a successful import today, in the afternoon (although if it's urgent it would
still be possible to make a CL updating a subset of tests in imported/wpt).

[panicker, 2017-01-04 21:08:02]

On 2017/01/04 18:59:28, qyearsley wrote:
> On 2017/01/04 at 06:07:31, yoav wrote:
> > They have indeed landed, but not imported.
> > I suspect that even if they would be imported, they will not successfully
run
> as simple tests (I think at least most of them need to be served as wptserve
> tests, and therefore block on
> https://bugs.chromium.org/p/chromium/issues/detail?id=669802).
> > 
> > I think we should manually import the tests into http/tests/w3c/approved
until
> the underlying issues are resolved and they are properly imported through the
> regular process.
> > sunjian@ / panicker@ - can one of you take on the manual import?
> > 
> > Adding qyearsley@ for comments on why they are not currently imported.
> 
> Not currently imported because the auto import job hasn't succeeded since Dec
25
>
(https://build.chromium.org/p/chromium.infra.cron/builders/w3c-test-autoroller)
> -- current problem is http://crbug.com/678077.
> 
> The documentation for manual import is still at
>
https://www.chromium.org/blink/importing-the-w3c-tests#TOC-Manually-Importing...
> -- although currently that will fail :-/ I really want to fix this issue and
get
Is the failure here the same as the failure that's tripping the auto import i.e.
http://crbug.com/678077 ?

> a successful import today, in the afternoon (although if it's urgent it would
> still be possible to make a CL updating a subset of tests in imported/wpt).
It's not super urgent (but must make the M57 branch cut) please keep us posted
though.

Could you comment on the other issue that Yoav mentioned: http://crbug/669802 ?
Will this block importing & running the tests even after the import issue is
addressed ?

[sunjian, 2017-01-05 01:55:07]

https://codereview.chromium.org/2582863002/diff/20001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/timing/PerformanceNavigationTiming.cpp
(right):

https://codereview.chromium.org/2582863002/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/timing/PerformanceNavigationTiming.cpp:48: :
PerformanceResourceTiming("navigation",
On 2016/12/19 21:42:00, panicker wrote:
> mention this change in CL description 

Done.

[qyearsley, 2017-01-05 18:55:03]

On 2017/01/04 at 21:08:02, panicker wrote:
> On 2017/01/04 18:59:28, qyearsley wrote:
> > On 2017/01/04 at 06:07:31, yoav wrote:
> > > They have indeed landed, but not imported.
> > > I suspect that even if they would be imported, they will not successfully
run
> > as simple tests (I think at least most of them need to be served as wptserve
> > tests, and therefore block on
> > https://bugs.chromium.org/p/chromium/issues/detail?id=669802).
> > > 
> > > I think we should manually import the tests into http/tests/w3c/approved
until
> > the underlying issues are resolved and they are properly imported through
the
> > regular process.
> > > sunjian@ / panicker@ - can one of you take on the manual import?
> > > 
> > > Adding qyearsley@ for comments on why they are not currently imported.
> > 
> > Not currently imported because the auto import job hasn't succeeded since
Dec 25
> >
(https://build.chromium.org/p/chromium.infra.cron/builders/w3c-test-autoroller)
> > -- current problem is http://crbug.com/678077.
> > 
> > The documentation for manual import is still at
> >
https://www.chromium.org/blink/importing-the-w3c-tests#TOC-Manually-Importing...
> > -- although currently that will fail :-/ I really want to fix this issue and
get
> Is the failure here the same as the failure that's tripping the auto import
i.e. http://crbug.com/678077 ?
> 
> > a successful import today, in the afternoon (although if it's urgent it
would
> > still be possible to make a CL updating a subset of tests in imported/wpt).
> It's not super urgent (but must make the M57 branch cut) please keep us posted
though.
> 
> Could you comment on the other issue that Yoav mentioned: http://crbug/669802
? Will this block importing & running the tests even after the import issue is
addressed ?

Probably not (most of the tests aren't) -- after the current import issue is
addressed (https://codereview.chromium.org/2610243002), the next step would be
to 
update the W3CImportExpectations file
(https://cs.chromium.org/chromium/src/third_party/WebKit/LayoutTests/W3CImport...)
to unskip navigation-timings, and then run `Tools/Scripts/update-w3c-deps wpt`
in a new branch.

After doing that or copying the files manually, you can check if the tests pass
as-is wit (`Tools/Scripts/run-webkit-tests imported/wpt/navigation-timings`).

[sunjian, 2017-01-11 22:52:43]

On 2017/01/04 06:07:31, Yoav Weiss wrote:
> They have indeed landed, but not imported.
> I suspect that even if they would be imported, they will not successfully run
as
> simple tests (I think at least most of them need to be served as wptserve
tests,
> and therefore block on
> https://bugs.chromium.org/p/chromium/issues/detail?id=669802).
> 
> I think we should manually import the tests into http/tests/w3c/approved until
> the underlying issues are resolved and they are properly imported through the
> regular process.
> sunjian@ / panicker@ - can one of you take on the manual import?
> 
> Adding qyearsley@ for comments on why they are not currently imported.

Hey Yoav, we have one landing patch,
https://codereview.chromium.org/2624553002/, for moving the tests into approved/
directory as you suggested. We have also confirmed that wptserve is not
available in imported/wpt which cause importing failures. Do you think you can
lgtm this one so that we can move on?

[Yoav Weiss, 2017-01-12 22:53:56]

On 2017/01/11 22:52:43, sunjian wrote:
> On 2017/01/04 06:07:31, Yoav Weiss wrote:
> > They have indeed landed, but not imported.
> > I suspect that even if they would be imported, they will not successfully
run
> as
> > simple tests (I think at least most of them need to be served as wptserve
> tests,
> > and therefore block on
> > https://bugs.chromium.org/p/chromium/issues/detail?id=669802).
> > 
> > I think we should manually import the tests into http/tests/w3c/approved
until
> > the underlying issues are resolved and they are properly imported through
the
> > regular process.
> > sunjian@ / panicker@ - can one of you take on the manual import?
> > 
> > Adding qyearsley@ for comments on why they are not currently imported.
> 
> Hey Yoav, we have one landing patch,
> https://codereview.chromium.org/2624553002/, for moving the tests into
approved/
> directory as you suggested. We have also confirmed that wptserve is not
> available in imported/wpt which cause importing failures. Do you think you can
> lgtm this one so that we can move on?

LGTM! :)

[sunjian, 2017-01-12 23:32:52]

The CQ bit was checked by sunjian@chromium.org

[sunjian, 2017-01-12 23:32:53]

The patchset sent to the CQ was uploaded after l-g-t-m from yoav@yoav.ws,
panicker@chromium.org
Link to the patchset: https://codereview.chromium.org/2582863002/#ps40001
(title: "made corresponding changes to one layout test")

[commit-bot: I haz the power, 2017-01-12 23:33:58]

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-01-13 01:43:17]

CQ is committing da patch.

Bot data: {"patchset_id": 40001, "attempt_start_ts": 1484263972814670,
"parent_rev": "e0bcd199795d70a6428d4b41860b2589a9c3652a", "commit_rev":
"59250b64593759462cdefbf4f411f1cca6e0c696"}

[commit-bot: I haz the power, 2017-01-13 01:43:54]

Description was changed from

==========
fixed encodedBodySize/decodedBodySize/initiatorType for nav timing 2. Report
initiatorType as "navigation" instead of an empty string.

BUG=675044,675042
==========

to

==========
fixed encodedBodySize/decodedBodySize/initiatorType for nav timing 2. Report
initiatorType as "navigation" instead of an empty string.

BUG=675044,675042

Review-Url: https://codereview.chromium.org/2582863002
Cr-Commit-Position: refs/heads/master@{#443445}
Committed:
https://chromium.googlesource.com/chromium/src/+/59250b64593759462cdefbf4f411...
==========

[commit-bot: I haz the power, 2017-01-13 01:43:55]

Committed patchset #2 (id:40001) as
https://chromium.googlesource.com/chromium/src/+/59250b64593759462cdefbf4f411...