CreateNonNetworkServiceURLLoader posts a task to send this trace. The NS or s13n sw path needs to do this as well.

bashi@: I understand that we have issues with NetworkService and ServiceWorkerServicification flags, but can you confirm that "Navigation timeToNetworkStack" works without those two flags?

e.g. I tried the following steps on Linux but the trace doesn't seems to work for me:
1. "out/Default/chrome --user-data-dir=/tmp/123 --disable-features=NetworkService,ServiceWorkerServicification"
2. Start recording
3. Open new tab
4. Paste https://servicification.com/ into Omnibox and hit enter
5. Stop recording

The produced trace contains two "Navigation timeToNetworkStack" begin:
1. The first one is for opening the new tab, and
2. The second one is for https://servicification.com/.

However the second one doesn't finish, and according to my log |frame_tree_node->navigation_request()->navigation_handle()| was |nullptr| for the begin trace:
https://cs.chromium.org/chromium/src/content/browser/frame_host/navigator_impl.cc?l=409&rcl=90c56ded9bfe169c3a6e19053f5f900154dfb321
(End trace has valid |navigation_handle_.get()| though)

I'm not sure but do we ignore end trace if the id doesn't match anything?

Thanks!

chongz@: Ah, good point. Looks like timeToNetwork doesn't finish even without NetworkService/ServiceWorkerServicification. I followed your instruction and confirmed that end markers for timeToNetwork aren't in the trace (IIUC the trace viewer adjusts end time for slices which don't have end markers).

I'm not sure what timeToNetworkStart is meant for, but I guess it should finish at some point?

Re #c8: Thanks for confirming!

clamy@ Do you have any context on whether we are still using this trace? Seems like it's been broken for a while without being noticed...

(Also +carlosk@ who added the trace initially.)

We added this to validate the improvements made by shipping PlzNavigate (they resided in a faster time to network start). We have validated the improvement, but I think some other teams have found it useful in the past.

+csharrison: I seem to remember that this trace helped you find some performance issues in the past. Is this correct?

+arthursonzogni: I think this may be linked to your work of changing the NavigationURLLoader implementation to be the same with and without the network service.

clamy: The metric that I used to discover a regression was the TimeToURLJobStart histogram, not the trace. My personal opinion is that we have too many "debugging" navigation async traces at the moment, so I am in favor of removing some that are more obvious if you have some other basic categories enabled like netlog.

I don't think this is a release blocker.

As noted above the trace is for developer use, and they have alternative histograms.

Will wait for a resolution on whether we needed this trace before fixing it for Network Service.

Ok, I'm fine with removing this trace.
+nasko, FYI

I've seen the regression in that trace for a bit, but never had the time to investigate why. Removing it sgtm.

Going to remove the trace as per #c11, #c14, and #c15.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/f130a8490aaadffae4c7fbdd3385ea9ff1a18c50

commit f130a8490aaadffae4c7fbdd3385ea9ff1a18c50
Author: Chong Zhang <chongz@chromium.org>
Date: Tue Sep 11 19:03:21 2018

Remoave trace 'Navigation timeToNetworkStack'

The trace is already broken and doesn't seem to be used. See bug for
more details.

Bug:  880129 
Change-Id: I822f24c2367a1acb76c1eeddade6b2ceefd1355a
Reviewed-on: https://chromium-review.googlesource.com/1216083
Reviewed-by: Camille Lamy <clamy@chromium.org>
Commit-Queue: Chong Zhang <chongz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#590429}
[modify] https://crrev.com/f130a8490aaadffae4c7fbdd3385ea9ff1a18c50/content/browser/frame_host/navigation_request.cc
[modify] https://crrev.com/f130a8490aaadffae4c7fbdd3385ea9ff1a18c50/content/browser/frame_host/navigator_impl.cc

+pasko@ for the metrics in 'android_startup_metric.html' which might need to be revised.

Closing this issue as fixed.