Most likely culprit: https://chromium-review.googlesource.com/c/chromium/src/+/841529

Eugene, do you have a good sample site that can trigger the download manager UI?  thinkbroadband.com/download isn't working for me.

Try this one: https://www.barebones.com/products/bbedit/download.html

file://123 will trigger download manager UI :)

Thanks Eugene and Srikanth!  I'm able to repro on ToT with the clean toolbar flag disabled, and am working on a fix now.

I've created crrev.com/c/874993 to fix this issue.  Since this is very late in the branch, we should consider what the best choice here should be.  Some options:

1) Land the CL and cherry-pick.  This solution has the greatest upside, since it will eliminate this bug for M64.  It's a 1-line change, and that change goes through |-updateToolbarState|, which was designed to be called repeatedly.  As such, adding a call here seems to be a minimal risk.  That being said, this is very late in the branch, and cherry-picking new changes may result in a different regression that will likely not be caught in time for the release.
2) Revert the CL that introduced the bug (crrev.com/c/841529).  This would reintroduce Issue 787795 (both the original bug and the secondary bug mentioned in comment 10).  The original bug where it's possible to load a page without a progress bar has potential security implications since users who are acclimated to this behavior could be susceptible to malicious pages that rewrite the DOM to look like a trusted page.  If the progress bar was not displayed for some page loads, this attack would require looking at the URL in the omnibox.
3) Don't cherry pick the new fix (crrev.com/c/87499), and leave the original fix (crrev.com/c/841529) on branch.  That would mean that this bug will NOT be fixed for M64.  That being said, I think that the security implications of having a hanging progress bar for download manager are far more benign than if we went with option (2).  Moreover, option (2) potentially could affect a wider range of page loads, as downloading files on iOS is a bit of an edge case.

I think that (1) is the best option because this seems like a low-risk change, and it would result in the best user experience.

I also prefer (1) not sure about others. Eugene, can you take a look?

Another option is not fixing this bug at all. (1) looks safe, but it indeed may result in a different (possibly more severe) regression.

Should we fix this bug for the respin instead?

Agreed.  While I'm fairly confident that the fix is low-risk, releasing it in a refresh would give us some time for more testing.  Since download manager is (at least in my browsing behavior) an edge case, this seems like a good combination of getting the fix for 64 while mitigating some of the risk of a late merge.

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

commit b0e6ca3348abcfa85501286b335844806e81c79e
Author: Kurt Horimoto <kkhorimoto@chromium.org>
Date: Thu Jan 18 22:17:39 2018

[iOS] Fix legacy toolbar progress bar for downloaded files.

The prior implementation of |-currentPageLoadStarted| directly called
|-startProgressBar| rather than going through |-updateToolbarState|.
|-updateToolbarState| changes the WebToolbarController's |loading|
property, and optionally calls |-startProgressBar| or
|-stopProgressBar| when the value changed.

When a file is downloaded, we receive |-currentPageLoadStarted| for
the started load, then immediatly receive |-updateToolbarState| when
the WebState::IsLoading() is reset to false (since the download manager
is native UI and isn't actually downloaded from the server).  Since
WebToolbarController's |loading| property was not getting reset to YES
in the |-currentPageLoadStarted| call, the |-updateToolbarState| call
with WebState::IsLoading() == false failed to hide the progress bar
since the value matches the WebToolbarController's previous |loading|
value.

This CL updates |-currentPageLoadStarted| to call |-updateToolbarState|
so that the internal property is consistent with the toolbar model and
the progress bar can be hidden correctly when the load finishes.

Bug:  802891 
Cq-Include-Trybots: master.tryserver.chromium.mac:ios-simulator-cronet;master.tryserver.chromium.mac:ios-simulator-full-configs
Change-Id: I6f88c501e8448752b1f4efaf61aef0e264953824
Reviewed-on: https://chromium-review.googlesource.com/874993
Reviewed-by: Sergio Collazos <sczs@chromium.org>
Reviewed-by: Eugene But <eugenebut@chromium.org>
Commit-Queue: Kurt Horimoto <kkhorimoto@chromium.org>
Cr-Commit-Position: refs/heads/master@{#530296}
[modify] https://crrev.com/b0e6ca3348abcfa85501286b335844806e81c79e/ios/chrome/browser/ui/toolbar/web_toolbar_controller.mm

The fix has landed.  Per offline discussion, I'm removing the RBS label from this bug.  In the event that we need to disable the clean toolbar in M65, this fix will be on that branch and the progress bar will behave correctly for download manager.

[Auto-generated comment by a script] We noticed that this issue is targeted for M-64; it appears the fix may have landed after branch point, meaning a merge might be required. Please confirm if a merge is required here - if so add Merge-Request-64 label, otherwise remove Merge-TBD label. Thanks.

Thanks!

Issue verified 
Version: Chrome Canary 66.0.3329.0
Device: iPhone 8
iOS: 11.1.2

No blue color progress bar indicator on download manager is displayed
https://drive.google.com/open?id=17ZIV556ipw-p4N2Coo8wQNj3p1VVUOC3