Note that the number of excess bolded characters matches the number of characters that hiding "https://" removed.

This is caused by some custom logic in HistoryURLProvider::SuggestExactInput that trims off HTTP in some cases and compensates for the number of characters.

It doesn't handle trimming off HTTPS currently.

I could modify it to handle trimming off HTTPS also, but it seems a bit unfortunate that it's using its own logic (to handle the view-source case in addition i imagine) as opposed to re-using the FormatURL / GetFormatTypes logic.

Any thoughts pkasting?

It does call FormatUrl().  Do you mean, it should be letting that adjust offsets or something?  I think offset adjustment long postdates this code.

It's a bit hard to know what you're proposing without seeing a CL for it.  If you've got a cleanup you think would be a win, write it up :)

Hey pkasting:

It calls FormatURL but with the trim HTTP flag off. It separate trims HTTP here:

https://cs.chromium.org/chromium/src/components/omnibox/browser/history_url_provider.cc?type=cs&q=HistoryURLProvider::SuggestExactInput&sq=package:chromium&l=578

and stores an offset.

The bug is that now HTTPS is being trimmed within FormatURL without storing that offset.

Without trawling through blame, my guess is still that this code predates offset adjustment, so it trims manually just so it can get the offset.

That said, TrimHttpPrefix() trims "http: plus up to two slashes".  I wonder if this difference is to handle the edge case where the user starts typing http:// at the beginning of something, so we trim sooner than FormatUrl() would?  I dunno.

I would suggest:
* Trying to trace this back to when it was first written to see justification (may have to go back past the initial public launch, we have that source history)
* Coding up a modified version and seeing how it interacts with typing schemes before/after you type the subsequent strings, especially right as the user is typing the :// part.

Great, thanks for the guidance.

I'll dig into this.

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

commit 9687abb7f32889c7bfcf7edaabc913e98e2f569d
Author: Tommy C. Li <tommycli@chromium.org>
Date: Mon Aug 07 17:46:11 2017

Omnibox UI Experiments: Fix HistoryURLProvider match text classification

Previously, the match.fill_into_edit URL formatting was roughly the
same as the match.contents formatting.

This CL fixes an issue where the offset calculation was shared between
the two. This is no longer appropriate since we are experimenting with
aggressive URL trimming on match.contents.

Bug:  739647 
Change-Id: I6f56da6de6d3441ad182a8b11471d652edbc51d9
Reviewed-on: https://chromium-review.googlesource.com/601061
Commit-Queue: Tommy Li <tommycli@chromium.org>
Reviewed-by: Peter Kasting <pkasting@chromium.org>
Cr-Commit-Position: refs/heads/master@{#492352}
[modify] https://crrev.com/9687abb7f32889c7bfcf7edaabc913e98e2f569d/components/omnibox/browser/history_url_provider.cc
[modify] https://crrev.com/9687abb7f32889c7bfcf7edaabc913e98e2f569d/components/omnibox/browser/history_url_provider_unittest.cc