Interesting find!

How prevalent is this interception logic? Does it happen for all navigations (i.e. we check all URLs against a list of native handlers)?

How typical is the delay?

In other words, do we have UMA? If not, would it be possible to add some?

It happens on all navigations and redirects. Technically the thread hop has been in place since forever: there used to be an InterceptResourceThrottle which was doing the same thread hop in the same case. The only difference with what used to be before is that we had to add an additional asynchronous check due to some issues in the tab destruction logic that would cause uaf bugs if we did synchronous checks.

I realize that I've been mistaken yesterday when Benoit and I spoke, the regression we observe when we introduced NavigationThrottles was on Windows, not on Android. This is because on Android the thread hop situation did not change: we introduced NavigationThrottles by transforming the InterceptResourceThrottle into an InterceptNavigationResourceThrottle. The version was synchronous at the time, we only made it asynchronous when we got uaf reports from the field. The change to asynchronous was only made later, when we got the uafs reports from the field. It was not picked up by bots, so I'm not sure how much of a delay this particular feature is causing.

The issue of the InterceptResourceThrottle itself delaying the navigation was already known when we started PlzNavigate. It'd be nice to see it improve though :).

Happily, the thread hop situation should become a bit better when PlzNavigate launches. Right now we have:
-> Browser UI thread: load url
-> Renderer: set up document loader & do request
-> Browser IO thread: set up request
-> Browser UI thread: NavigationThrottle::WillStartRequest
-> Browser IO thread: start network request
(if redirects:
-> Browser UI thread: NavigationThrottle::WillRedirectRequest
-> Browser IO thread: send IPC to renderer & wait for response
-> Renderer: check if redirect should be followed
-> Browser IO thread: follow redirect)
-> Browser UI thread: NavigationThrottle::WillProcessResponse
-> Browser IO thread: send response to renderer
-> Renderer: commit navigation

With PlzNavigate this becomes:
-> Browser UI thread: load url & NavigationThrottle::WillStartRequest
-> Browser IO thread: start network request
(if redirects:
-> Browser UI thread: NavigationThrottle::WillRedirectRequest which decides if redirect should be followed
-> Browser IO thread: follow redirect)
-> Browser UI thread: NavigationThrottle::WillProcessResponse & send stream endpoint to renderer
-> Renderer: request stream data
-> Browser IO thread: send stream data
-> Renderer: commit navigation

(Note that we plan to eventually get rid of the renderer requesting the stream in the end, but this requires significant changes to blink, so we're postponing that until later).

In any case, we should have a lot less hops, so this should be less of an issue. I think it'd be better to look at this issue once we have launched PlzNavigate, as the induced delay may be greatly reduced by the architectural change.

When it comes to timing NavigationThrottles, I've had this idea of imposing users of the class to add a name for their throttle and add histograms (Like FooNavigationThrottle::WillStartRequestTime for example) that the navigation code would record automatically each time it calls the throttles. This way we would have good & precise monitoring in the field. I've not had the time to push the idea yet, but it's been on my roadmap for better navigations for some time.

Thanks for the extra details, highly appreciated.

Agree on waiting after PlzNavigate.
Is issue 576261 the right bug to block on?

No we have a meta-bug in issue 368813. Adding it as a blocker.

Re #1: About the delay, I expect it to be fully on the critical path for external intents coming from a well-behaved external app on Android. Google Search on Android is one of them. I can't give numbers on a public bug, but as you know, it's a large fraction of navigations.

For other navigations, the delay is likely much lower, as the UI thread is less likely to be busy.

Checking today, seems that it was solved in  crbug.com/732260 , which is fixed.

Yeah! \o/

In chrome 57, NavigationResourceThrottle::WillProcessResponse --> WillProcessResponseOnUIThread, this thread hop will cost more than 100ms in shouldInterceptRequest case, sometimes more than 500ms in low-end phone. shouldInterceptRequest is key interface for offline, so this thread hop cost will take badly affect for offline performance.