cthomp would you want to take this? It'd be a good warmup for the EV project, it's pretty similar work.

Sure!

Interesting side comment that might help put this metric in context.

For M-63, I added the metric Omnibox.URLNavigationScheme.
>>>
The scheme of the destination URL for the selected omnibox suggestion. This could be a what-you-typed suggestion (if the user fully typed a URL), an inline autocompletion, or something in the dropdown, anything as long as it's a URL navigation, not a search query. Excludes omnibox URL navigations that are effectively reloads as well as cut-and-pastes of URLs. Also does not take into account any redirects that destination URL may do before finally serving a page. In other words, it's the scheme of the first request in a possible chain.
>>>
It shows that a slight majority of omnibox URL navigations (TYPED navigations) start with an http request (compared with an https request).  The timing data cthomp@ will measure will be on this slice.

I have a WIP CL adding this metric at crrev.com/c/818493.

Currently I'm investigating a potential double counting problem, although I can't replicate it anymore. It seemed like one of the Omnibox prediction services could cause a navigation to be triggered with PAGE_TRANSITION_TYPED (which causes the throttle code to activate and add to the histogram). It did not consistently happen on every URL navigation though, and I can't trigger it on my latest build.

I believe there is some sort of preloading happening the omnibox (NoState prefetch?).  I think it mostly triggers when you regularly (i) type the same text, (ii) see the same inline autocompletion to a URL, and (iii) hit enter.  At some point, I think the page will start getting fetched after step (ii).

One possibility is to do something like
https://cs.chromium.org/chromium/src/chrome/browser/page_load_metrics/observers/omnibox_suggestion_used_page_load_metrics_observer.h
and only emit the histogram once the page paints.  That way the possible errant extra requests won't matter.

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

commit 4137cec0bf72fbb54be3dea801a364446f503a49
Author: Christopher Thompson <cthomp@chromium.org>
Date: Tue Dec 19 05:34:23 2017

Measure time of HTTPS upgrades of typed navigations

This adds a new histogram and a navigation throttle to measure how long
it takes when a user completes a typed URL navigation in the omnibox
with HTTP but then is redirected to HTTPS (if such a redirect occurs).
This will help measure possible performance benefits of having
autocomplete suggest the HTTPS version directly for such URLs.

Bug:  793145 
Change-Id: I78819b57b1a83675b40b2e21127ff497d06e96ba
Reviewed-on: https://chromium-review.googlesource.com/818493
Commit-Queue: Christopher Thompson <cthomp@chromium.org>
Reviewed-by: Mark Pearson <mpearson@chromium.org>
Reviewed-by: Emily Stark <estark@chromium.org>
Cr-Commit-Position: refs/heads/master@{#524948}
[modify] https://crrev.com/4137cec0bf72fbb54be3dea801a364446f503a49/chrome/browser/BUILD.gn
[modify] https://crrev.com/4137cec0bf72fbb54be3dea801a364446f503a49/chrome/browser/chrome_content_browser_client.cc
[add] https://crrev.com/4137cec0bf72fbb54be3dea801a364446f503a49/chrome/browser/ssl/typed_navigation_timing_throttle.cc
[add] https://crrev.com/4137cec0bf72fbb54be3dea801a364446f503a49/chrome/browser/ssl/typed_navigation_timing_throttle.h
[add] https://crrev.com/4137cec0bf72fbb54be3dea801a364446f503a49/chrome/browser/ssl/typed_navigation_timing_throttle_browsertest.cc
[add] https://crrev.com/4137cec0bf72fbb54be3dea801a364446f503a49/chrome/browser/ssl/typed_navigation_timing_throttle_unittest.cc
[modify] https://crrev.com/4137cec0bf72fbb54be3dea801a364446f503a49/chrome/test/BUILD.gn
[modify] https://crrev.com/4137cec0bf72fbb54be3dea801a364446f503a49/tools/metrics/histograms/histograms.xml