service worker: Add a netlog event for navigation preload

service worker: Add a netlog event for navigation preload

This will aid debuggability and investigation. I expect we'll get a lot
of ERR_ABORT from sites that enable navigation preload but don't use it
on every navigation.

BUG=649558
Review-Url: https://codereview.chromium.org/2818543005
Cr-Commit-Position: refs/heads/master@{#464426}
Committed: https://chromium.googlesource.com/chromium/src/+/d348e46e81ea3d4996ee304ac47bc6b47495a7c4

[falken, 2017-04-13 08:46:49]

falken@chromium.org changed reviewers:
+ horo@chromium.org, mmenke@chromium.org, yhirano@chromium.org

[falken, 2017-04-13 08:46:50]

yhirano, mmenke: ptal

[falken, 2017-04-13 08:48:32]

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

[commit-bot: I haz the power, 2017-04-13 08:49:03]

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-04-13 09:55:57]

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

[commit-bot: I haz the power, 2017-04-13 09:55:58]

Dry run: This issue passed the CQ dry run.

[mmenke, 2017-04-13 14:53:09]

On 2017/04/13 08:46:50, falken wrote:
> yhirano, mmenke: ptal

With servicification of the network stack, we'll most likely be moving towards
getting ServiceWorker out of the network process, and it will most likely lose
access to the NetLog (I don't think we really want a Mojo API to log to NetLog).
 We'll certainly be removing the concept of navigation preloads from the network
service.

Given that, I wonder if there's something else we could do, that would live
beyond network stack servicification.

[falken, 2017-04-13 15:31:34]

On 2017/04/13 14:53:09, mmenke wrote:
> On 2017/04/13 08:46:50, falken wrote:
> > yhirano, mmenke: ptal
> 
> With servicification of the network stack, we'll most likely be moving towards
> getting ServiceWorker out of the network process, and it will most likely lose
> access to the NetLog (I don't think we really want a Mojo API to log to
NetLog).
>  We'll certainly be removing the concept of navigation preloads from the
network
> service.
> 
> Given that, I wonder if there's something else we could do, that would live
> beyond network stack servicification.

Yes, this is intended to be temporary. I agree with the direction of
servicification and extracting service worker from the network stack.

But what do you have in mind? I imagine even with servicified service worker, a
navigation preload would still trigger a request that shows up in NetLog, no? Or
would service worker have its own version of NetLog?

For the time being, since navigation preload is shipping, I think it'd be
valuable to be able to identify those requests in NetLog.

[mmenke, 2017-04-13 15:38:37]

On 2017/04/13 15:31:34, falken wrote:
> On 2017/04/13 14:53:09, mmenke wrote:
> > On 2017/04/13 08:46:50, falken wrote:
> > > yhirano, mmenke: ptal
> > 
> > With servicification of the network stack, we'll most likely be moving
towards
> > getting ServiceWorker out of the network process, and it will most likely
lose
> > access to the NetLog (I don't think we really want a Mojo API to log to
> NetLog).
> >  We'll certainly be removing the concept of navigation preloads from the
> network
> > service.
> > 
> > Given that, I wonder if there's something else we could do, that would live
> > beyond network stack servicification.
> 
> Yes, this is intended to be temporary. I agree with the direction of
> servicification and extracting service worker from the network stack.
> 
> But what do you have in mind? I imagine even with servicified service worker,
a
> navigation preload would still trigger a request that shows up in NetLog, no?
Or
> would service worker have its own version of NetLog?

Network requests certainly would, as would foreign fetch requests.  It's not
clear if the first request handled by service worker would, however.  I was
thinking maybe tracing?  I'm not really sure what would be useful to you guys,
as I don't debug SW requests.

> For the time being, since navigation preload is shipping, I think it'd be
> valuable to be able to identify those requests in NetLog.

Anyhow, if this is only temporary, and it's fine if this is lost while setting
up the network service (As opposed to something else blocking progress - i.e.,
if we split up the guts of RDH and end up losing this, not a big deal), LGTM.

[falken, 2017-04-13 15:55:21]

On 2017/04/13 15:38:37, mmenke wrote:
> On 2017/04/13 15:31:34, falken wrote:
> > On 2017/04/13 14:53:09, mmenke wrote:
> > > On 2017/04/13 08:46:50, falken wrote:
> > > > yhirano, mmenke: ptal
> > > 
> > > With servicification of the network stack, we'll most likely be moving
> towards
> > > getting ServiceWorker out of the network process, and it will most likely
> lose
> > > access to the NetLog (I don't think we really want a Mojo API to log to
> > NetLog).
> > >  We'll certainly be removing the concept of navigation preloads from the
> > network
> > > service.
> > > 
> > > Given that, I wonder if there's something else we could do, that would
live
> > > beyond network stack servicification.
> > 
> > Yes, this is intended to be temporary. I agree with the direction of
> > servicification and extracting service worker from the network stack.
> > 
> > But what do you have in mind? I imagine even with servicified service
worker,
> a
> > navigation preload would still trigger a request that shows up in NetLog,
no?
> Or
> > would service worker have its own version of NetLog?
> 
> Network requests certainly would, as would foreign fetch requests.  It's not
> clear if the first request handled by service worker would, however.  I was
> thinking maybe tracing?  I'm not really sure what would be useful to you guys,
> as I don't debug SW requests.

Ah yes, navigation preload actually is always a network request. I agree that if
it doesn't hit network it shouldn't go to the NetLog.

The response for the navigation preload request goes to the service worker, and
it can choose to respond to the fetch event triggered by the navigation using
the response.

> 
> > For the time being, since navigation preload is shipping, I think it'd be
> > valuable to be able to identify those requests in NetLog.
> 
> Anyhow, if this is only temporary, and it's fine if this is lost while setting
> up the network service (As opposed to something else blocking progress - i.e.,
> if we split up the guts of RDH and end up losing this, not a big deal), LGTM.

Thanks, that makes sense to me.

[falken, 2017-04-13 15:58:37]

The CQ bit was checked by falken@chromium.org

[commit-bot: I haz the power, 2017-04-13 15:59: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, 2017-04-13 16:05:47]

CQ is committing da patch.

Bot data: {"patchset_id": 1, "attempt_start_ts": 1492099117248390, "parent_rev":
"995002514a6d75ab8065ff7e995ea9e9a1a93951", "commit_rev":
"d348e46e81ea3d4996ee304ac47bc6b47495a7c4"}

[commit-bot: I haz the power, 2017-04-13 16:06:41]

Description was changed from

==========
service worker: Add a netlog event for navigation preload

This will aid debuggability and investigation. I expect we'll get a lot
of ERR_ABORT from sites that enable navigation preload but don't use it
on every navigation.

BUG=649558
==========

to

==========
service worker: Add a netlog event for navigation preload

This will aid debuggability and investigation. I expect we'll get a lot
of ERR_ABORT from sites that enable navigation preload but don't use it
on every navigation.

BUG=649558

Review-Url: https://codereview.chromium.org/2818543005
Cr-Commit-Position: refs/heads/master@{#464426}
Committed:
https://chromium.googlesource.com/chromium/src/+/d348e46e81ea3d4996ee304ac47b...
==========

[commit-bot: I haz the power, 2017-04-13 16:06:42]

Committed patchset #1 (id:1) as
https://chromium.googlesource.com/chromium/src/+/d348e46e81ea3d4996ee304ac47b...