For completeness, here's the dump for net-internals:

URL_REQUEST
http://www.wellsfargo.com/
Start Time: 2017-09-07 15:23:40.962

t= 45 [st=  0] +REQUEST_ALIVE  [dt=672]
                --> priority = "HIGHEST"
                --> url = "http://www.wellsfargo.com/"
t= 45 [st=  0]    DELEGATE_INFO  [dt=0]
                  --> delegate_blocked_by = "NavigationResourceThrottle"
t= 45 [st=  0]    URL_REQUEST_DELEGATE  [dt=0]
t= 45 [st=  0]   +URL_REQUEST_START_JOB  [dt=63]
                  --> load_flags = 37120 (MAIN_FRAME_DEPRECATED | MAYBE_USER_GESTURE | VERIFY_EV_CERT)
                  --> method = "GET"
                  --> url = "http://www.wellsfargo.com/"
t= 45 [st=  0]      URL_REQUEST_DELEGATE  [dt=0]
t= 45 [st=  0]      HTTP_CACHE_GET_BACKEND  [dt=0]
t= 45 [st=  0]      HTTP_CACHE_OPEN_ENTRY  [dt=1]
                    --> net_error = -2 (ERR_FAILED)
t= 46 [st=  1]      HTTP_CACHE_CREATE_ENTRY  [dt=0]
t= 46 [st=  1]      HTTP_CACHE_ADD_TO_ENTRY  [dt=0]
t= 46 [st=  1]     +HTTP_STREAM_REQUEST  [dt=8]
t= 46 [st=  1]        HTTP_STREAM_JOB_CONTROLLER_BOUND
                      --> source_dependency = 1089 (HTTP_STREAM_JOB_CONTROLLER)
t= 54 [st=  9]        HTTP_STREAM_REQUEST_BOUND_TO_JOB
                      --> source_dependency = 1090 (HTTP_STREAM_JOB)
t= 54 [st=  9]     -HTTP_STREAM_REQUEST
t= 54 [st=  9]     +HTTP_TRANSACTION_SEND_REQUEST  [dt=1]
t= 55 [st= 10]        HTTP_TRANSACTION_SEND_REQUEST_HEADERS
                      --> GET / HTTP/1.1
                          Host: www.wellsfargo.com
                          Connection: keep-alive
                          Upgrade-Insecure-Requests: 1
                          User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.79 Safari/537.36
                          Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
                          Accept-Encoding: gzip, deflate
                          Accept-Language: en-US,en;q=0.8
t= 55 [st= 10]     -HTTP_TRANSACTION_SEND_REQUEST
t= 55 [st= 10]     +HTTP_TRANSACTION_READ_HEADERS  [dt=51]
t= 55 [st= 10]        HTTP_STREAM_PARSER_READ_HEADERS  [dt=51]
t=106 [st= 61]        HTTP_TRANSACTION_READ_RESPONSE_HEADERS
                      --> HTTP/1.0 301 Moved Permanently
                          Location: https://www.wellsfargo.com
                          Server: KONICHIWA/1.1
                          Connection: Keep-Alive
                          Content-Length: 0
t=106 [st= 61]     -HTTP_TRANSACTION_READ_HEADERS
t=106 [st= 61]      HTTP_CACHE_WRITE_INFO  [dt=0]
t=106 [st= 61]      HTTP_CACHE_WRITE_DATA  [dt=0]
t=106 [st= 61]      HTTP_CACHE_WRITE_INFO  [dt=0]
t=106 [st= 61]      URL_REQUEST_DELEGATE  [dt=0]
t=107 [st= 62]     +URL_REQUEST_DELEGATE  [dt=1]
t=107 [st= 62]        DELEGATE_INFO  [dt=0]
                      --> delegate_blocked_by = "NavigationResourceThrottle"
t=107 [st= 62]        DELEGATE_INFO  [dt=1]
                      --> delegate_blocked_by = "AsyncResourceHandler"
t=108 [st= 63]     -URL_REQUEST_DELEGATE
t=108 [st= 63]      URL_REQUEST_REDIRECTED
                    --> location = "https://www.wellsfargo.com/"
t=108 [st= 63]   -URL_REQUEST_START_JOB
t=108 [st= 63]    URL_REQUEST_DELEGATE  [dt=0]
t=108 [st= 63]   +URL_REQUEST_START_JOB  [dt=558]
                  --> load_flags = 37120 (MAIN_FRAME_DEPRECATED | MAYBE_USER_GESTURE | VERIFY_EV_CERT)
                  --> method = "GET"
                  --> url = "https://www.wellsfargo.com/"
t=108 [st= 63]      URL_REQUEST_DELEGATE  [dt=0]
t=108 [st= 63]      HTTP_CACHE_GET_BACKEND  [dt=0]
t=108 [st= 63]      HTTP_CACHE_OPEN_ENTRY  [dt=0]
                    --> net_error = -2 (ERR_FAILED)
t=108 [st= 63]      HTTP_CACHE_CREATE_ENTRY  [dt=0]
t=108 [st= 63]      HTTP_CACHE_ADD_TO_ENTRY  [dt=1]
t=109 [st= 64]     +HTTP_STREAM_REQUEST  [dt=174]
t=109 [st= 64]        HTTP_STREAM_JOB_CONTROLLER_BOUND
                      --> source_dependency = 1101 (HTTP_STREAM_JOB_CONTROLLER)
t=283 [st=238]        HTTP_STREAM_REQUEST_BOUND_TO_JOB
                      --> source_dependency = 1102 (HTTP_STREAM_JOB)
t=283 [st=238]     -HTTP_STREAM_REQUEST
t=283 [st=238]     +HTTP_TRANSACTION_SEND_REQUEST  [dt=0]
t=283 [st=238]        HTTP_TRANSACTION_SEND_REQUEST_HEADERS
                      --> GET / HTTP/1.1
                          Host: www.wellsfargo.com
                          Connection: keep-alive
                          Upgrade-Insecure-Requests: 1
                          User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.79 Safari/537.36
                          Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
                          Accept-Encoding: gzip, deflate, br
                          Accept-Language: en-US,en;q=0.8
t=283 [st=238]     -HTTP_TRANSACTION_SEND_REQUEST
t=283 [st=238]     +HTTP_TRANSACTION_READ_HEADERS  [dt=382]
t=283 [st=238]        HTTP_STREAM_PARSER_READ_HEADERS  [dt=382]
t=665 [st=620]        HTTP_TRANSACTION_READ_RESPONSE_HEADERS
                      --> HTTP/1.1 200 OK
                          Date: Thu, 07 Sep 2017 22:23:41 GMT
                          Content-Type: text/html; charset=UTF-8
                          Transfer-Encoding: chunked
                          Connection: keep-alive
                          Expires: Thu, 01 Jan 1970 00:00:00 GMT
                          Cache-control: no-cache
                          Cache-control: no-store, private
                          Set-cookie: [75 bytes were stripped]
                          Set-cookie: [122 bytes were stripped]
                          Set-cookie: [106 bytes were stripped]
                          Set-cookie: [133 bytes were stripped]
                          Server: KONICHIWA/2.0
                          X-xss-protection: 1; mode=block
                          X-ua-compatible: IE=edge
                          Pragma: no-cache
                          X-frame-options: SAMEORIGIN
                          Content-Encoding: gzip
t=665 [st=620]     -HTTP_TRANSACTION_READ_HEADERS
t=665 [st=620]      HTTP_CACHE_WRITE_INFO  [dt=0]
t=665 [st=620]      URL_REQUEST_DELEGATE  [dt=0]
t=666 [st=621]      URL_REQUEST_FILTERS_SET
                    --> filters = "GZIP"
t=666 [st=621]   -URL_REQUEST_START_JOB
t=666 [st=621]   +URL_REQUEST_DELEGATE  [dt=0]
t=666 [st=621]      DELEGATE_INFO  [dt=0]
                    --> delegate_blocked_by = "NavigationResourceThrottle"
t=666 [st=621]   -URL_REQUEST_DELEGATE
t=666 [st=621]    HTTP_TRANSACTION_READ_BODY  [dt=0]
t=666 [st=621]    URL_REQUEST_JOB_BYTES_READ
                  --> byte_count = 3198
t=667 [st=622]    URL_REQUEST_JOB_FILTERED_BYTES_READ
                  --> byte_count = 11111
t=667 [st=622]    HTTP_TRANSACTION_READ_BODY  [dt=0]
t=667 [st=622]    URL_REQUEST_JOB_BYTES_READ
                  --> byte_count = 3683
t=667 [st=622]    URL_REQUEST_JOB_FILTERED_BYTES_READ
                  --> byte_count = 20757
t=667 [st=622]    HTTP_TRANSACTION_READ_BODY  [dt=0]
t=667 [st=622]    URL_REQUEST_JOB_BYTES_READ
                  --> byte_count = 20688
t=668 [st=623]    URL_REQUEST_JOB_FILTERED_BYTES_READ
                  --> byte_count = 32768
t=669 [st=624]    URL_REQUEST_JOB_FILTERED_BYTES_READ
                  --> byte_count = 32768
t=669 [st=624]    URL_REQUEST_JOB_FILTERED_BYTES_READ
                  --> byte_count = 32768
t=670 [st=625]    HTTP_TRANSACTION_READ_BODY  [dt=46]
t=716 [st=671]    URL_REQUEST_JOB_BYTES_READ
                  --> byte_count = 9604
t=716 [st=671]    URL_REQUEST_JOB_FILTERED_BYTES_READ
                  --> byte_count = 32768
t=716 [st=671]    HTTP_TRANSACTION_READ_BODY  [dt=1]
t=717 [st=672]    URL_REQUEST_JOB_BYTES_READ
                  --> byte_count = 8506
t=717 [st=672]    URL_REQUEST_JOB_FILTERED_BYTES_READ
                  --> byte_count = 32768
t=717 [st=672]    URL_REQUEST_JOB_FILTERED_BYTES_READ
                  --> byte_count = 10577
t=717 [st=672]    HTTP_TRANSACTION_READ_BODY  [dt=0]
t=717 [st=672] -REQUEST_ALIVE

It looks like this is intentional.  Chrome excludes redirects from incrementing the typed count.
https://cs.chromium.org/chromium/src/components/history/core/browser/history_backend.cc?l=787

I traced this back with git blame to the initial comment.  This behavior has existed for a long time.

In the process, I found a comment from pkasting@ arguing that Chrome should exclude redirects from incrementing typed counts.  See b/1148304

Assigning to pkasting@ to resolve his disagreement with himself. :-)

Can you paste that comment?  I don't have easy buganizer access atm.

Indeed, we explicitly exclude redirects in HistoryBackend::AddPageVisit().

I remember writing this and debating what to do.  The middle entries of a redirect chain pretty clearly shouldn't be marked as "typed".  The first one definitely should.  But the last one isn't clear; the user hasn't directly typed it, and marking it as such could make the omnibox behavior wonky, but not marking it prevents boostrapping new URLs.

I don't know whether there's a middle ground where we mark this as typed when it's not "substantially different" than the chain start.  Another middle ground would be to add some sort of more fine-grained stat tracking than visit and typed counts (e.g. distinguish between "link clicked", "visited via omnibox", and "visited via typing this URL directly in the omnibox" and then changing the history provider scoring.  That sounds way too big and not likely to provide a huge win.

I also wonder if this is why bug 701091 isn't fixed yet.

I don't know how to resolve this and I don't have the mental bandwidth to own it.

> Can you paste that comment?
Not easily.  You made multiple comments on that thread, including some referencing file attachments.  If you want I can attach a PDF of the whole thread along with the file attachments to this bug thread, though that seems unnecessarily heavy-handed.

Given your comment above "I remember writing this and debating what to do.  ...", you're implying that we should not be marking redirects as typed or at minimum not incrementing the typed count for redirects.  This statement is consistent with your previous comment on the bug thread and consistent with current behavior.

There could be a middle ground of http<->https, a la what I proposed on bug 542484 comment 27.  Perhaps here we can increment the typed count of the https page if a page does a http->https redirection.  This helps promote https sites.  It'll complement whatever improvement we make to bug 542484.

I don't think there's a middle ground for more fine-grained stat collecting.

And, yes, I'm pretty sure this is the reason why bug 701091 exists.  In the code when checking whether an intranet site is a known host, we look for typed counts > 0.  If we're not incrementing typed counts during redirects, then that's an obvious issue here.

Again, I'm willing to go with WontFix on this bug, or maybe implementing the first middle ground I mention.  But, regardless, we need to clearly understand that all pages on redirect chains will likely not have similar scores (unlike, say, what was claimed on bug 542484 comment 26).

I'm fairly sure we should do something rather than do nothing.  I'm less sure what the something is.  I'd either just mark the chain_end as typed and hope it doesn't cause too much weirdness, or I'd put in something that says "mark it as typed if it's an intranet URL or has the same hostname as the chain start".  Maybe that heuristic would catch most of the redirects that matter while excluding the sorts of things that would confuse users.

Untriaged -> Available, as we want to do something and have a couple of ideas.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

mpearson: assigning to you for your latest thoughts. Feel free to unassign yourself when done. Should we just NextAction it? Is it worth putting on the list of potential Q4 or Q1 work? I'm unclear on what the severity of this issue is.

I think the fix bug 542484 handled the common case, including the example in the original report.

There might be something else to do there.  How often do users go somewhere by typing part of a URL / title and that page redirects, then the user tries again later to go to the page using the omnibox and types part of the URL/title of the redirect, not part of the URL/title of the original page?  That sounds unlikely to me.

I might even WontFix this.  My instinct says it's relatively low priority.

The NextAction date has arrived: 2019-01-08