I'm not convinced that's a bug.  Why would hitting the reload button, which doesn't navigate away, change the fact that the current site downloaded multiple files?

Is this different from how we handle other permissions?  Has it changed earlier than M58?  (Sort of odd to say "not a regression" but then give an earliest version that's the current dev channel.)

@dmascarenhas - Request you to please update as requested above. Leaving the issue status as Untriaged.

With response to comment #1&#2 :

If we ‘Allow’ Location option  or ‘Block’ Popup option from permission bubble and click ’Popup (delay 2 seconds)’ button on https://permission.site/  and then reload the page then Icon beside star icon vanishes, which is not same for above testcase (i.e. AutoDownload icon) . Please refer screencast

@pkasting:Please take a look.

Deleted: Actual.mov 11.1 MB

Actual.mov 11.1 MB Download

This is probably a result of crrev.com/2561673003, which allowed the auto download page action to start showing. +cc alshabalin.

I think the correct behaviour would be to hide the Auto Download icon after the refresh. Other permissions are only shown as page actions when they're actively been accessed (so a page with location permission will only show a page action when the page actually tries to access location).

Probably makes sense to hide icon on all IsInMainFrame() && HasCommitted() && !IsSamePage() navigations until there's another download request.

So, if a visible icon state becomes different from the actual permission state on tab, it makes sense to use TabSpecificContentSettings again. DownloadRequestLimiter is then responsible for the actual permission on current tab, TabSpecificContentSettings – for the visible permission.

Kicking over to UI>Browser>Permissions>Indicators for traige, as this an issue with indicators (in the omnibox), not the omnibox itself.

Taking another look at this.

I don't think using TabSpecificContentSettings is the right move. It will still need some way of being told from the download request limiter that there was a download and that the icon needs to change. That information is all in the request limiter, and the only way the limiter can inform the outside world a change has happened is through the content::NotificationService() call.

I think introducing a new UiState on the request limiter and updating that along with the download status is the right way to address this. Now working on it.

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

commit 602b9632febd73e838fefd440845000e22e01eb3
Author: Dominick Ng <dominickn@chromium.org>
Date: Thu Nov 16 07:49:39 2017

Only show the automatic downloads omnibox icon after a download.

This CL addresses an issue where reloading a page with a persisted
automatic downloads permission retained the omnibox indicator after the
reload - even if a download had not been triggered. This is inconsistent
with other permission indicators, which only appear in the omnibox when
they are actively used.

A new DownloadUiState is introduced in the DownloadRequestLimiter to
allow the UI to have a different state to the internal download state.
The primary difference is that the UI state remains DEFAULT (nothing) if
the page has not invoked a download during the current load. Once a
download is invoked, the UI state will be updated if the automatic
download permission is granted or denied by the user. Every time a
download is intitiated, changes in the UI state will be broadcast so
that the omnibox indicator updates as necessary.

BUG= 701680 

Change-Id: Iba48ee833422ebdf6111c91fa826758b9e1ceef3
Reviewed-on: https://chromium-review.googlesource.com/770639
Commit-Queue: Dominick Ng <dominickn@chromium.org>
Reviewed-by: David Trainor <dtrainor@chromium.org>
Reviewed-by: Trent Apted <tapted@chromium.org>
Cr-Commit-Position: refs/heads/master@{#517019}
[modify] https://crrev.com/602b9632febd73e838fefd440845000e22e01eb3/chrome/browser/download/download_browsertest.cc
[modify] https://crrev.com/602b9632febd73e838fefd440845000e22e01eb3/chrome/browser/download/download_request_limiter.cc
[modify] https://crrev.com/602b9632febd73e838fefd440845000e22e01eb3/chrome/browser/download/download_request_limiter.h
[modify] https://crrev.com/602b9632febd73e838fefd440845000e22e01eb3/chrome/browser/download/download_request_limiter_unittest.cc
[modify] https://crrev.com/602b9632febd73e838fefd440845000e22e01eb3/chrome/browser/ui/cocoa/content_settings/content_setting_bubble_cocoa_browsertest.mm
[modify] https://crrev.com/602b9632febd73e838fefd440845000e22e01eb3/chrome/browser/ui/content_settings/content_setting_bubble_model.cc
[modify] https://crrev.com/602b9632febd73e838fefd440845000e22e01eb3/chrome/browser/ui/content_settings/content_setting_image_model.cc
[modify] https://crrev.com/602b9632febd73e838fefd440845000e22e01eb3/chrome/browser/ui/content_settings/content_setting_image_model_browsertest.cc
[modify] https://crrev.com/602b9632febd73e838fefd440845000e22e01eb3/chrome/browser/ui/views/location_bar/content_setting_bubble_dialog_browsertest.cc

The limiter would only need to inform TabSpecificContentSettings which it can get via WebContents (precisely the one it uses for NotificationService). And the point of working with TabSpecificContentSettings is to get all the default hiding rules for content setting icons for consistency sake.

However, your solution is also fine because of the conflict between the default rule and DRL rule of handling navigation (the latter cares if the navigation was renderer-initiated, the former will drop the setting regardless).

c#11: thanks for the analysis - the default rule conflict was another reason why I went with this approach since it required less ping-ponging to change and update the download state.

This should roll out with M64 (it should be in tomorrow's Canary). Closing as Fixed and awaiting verification.