I think we can do something similar to the "Manage search engines" table and just have the icon appear at the start of the "Website" column.

@bettes, let us know if you'd prefer a different treatment here.

Thanks for taking a look.

Attaching screenshot of icons for passwords

Deleted: icons.png 61.0 KB

	icons.png 61.0 KB View Download

In the attached screenshot, all the cases where an icon is not displayed are bogus websites (localhost, other-machine). Do those websites provide favicons in the first place?

In order to really prove that there is a problem with the favicon mechanism you should,
 1) Add a password for a website that has a favicon.
 2) Visit that website once.
 3) Refresh the settings page and see if the icon exists.

Added an icon to local host, icon is now on page.

Is this working as intended? Or is there another issue w/ the icons?

Deleted: more_icons.png 60.4 KB

	more_icons.png 60.4 KB View Download

Note that  issue 608069  is referring only to search engines related icons.

Is this working as intended? Maybe yes. Here is the catch that might make it seem that it does not.

 1) Launch Chrome in a new local profile (using --user-data-dir=/tmp/foo)
 2) Open settings and login to Chrome with an existing account (make sure password syncing is enabled.
 3) Navigate to chrome://settings/passwords (old or new settings). Because the user has never visited the website corresponding to each synced password yet, the default favicon is displayed. 
 4) Visit one of those websites directly
 5) Reload the settings tab. Expecting the favicon of the website that was just visited to show up, and everything else to use the default icon.

In short, the catch is that favicons are populated with user navigation only.

The behaviour from #12 looks correct to me. I asked and the reporter of this bug will check the current way the settings work.

I agree that icons works a intended. Thanks, Hector! An icon is available only if there is the corresponding entry in history. It is how old password settings, bookmarks and other pages work. So, I believe that this issue is not blocked on  issue 608069  (which of course would be nice to fix). 

We have a known issue about how we populate favicons in chrome settings. Because the page looked broken with a list of empty favicons, we chose to remove them. Until we can resolve this, the Passwords section is WAI.  Scanability may be comprised a bit, but for those venturing into this page, it's not un-usable. 

Documentation can be found here:  http://crbug.com/608069 

Removing blocker per comments #12-14.

@bettes:  issue 608069  is only referring to search engine icons, it is unrelated to password icons. Per discussion at 12-14, it is it does not seem that there is any problem with password related icons.

It's the same password fetching mechanism, so while it's WAI it's not ideal.

bettes@ mentioned in our converstation that it would be better to not have icons than to have mostly blank icons.

Once  Issue 608069  is resolved, it would be good to resolve this one. This issue is still blocked on it, but it shouldn't block  Issue 671375  or  Issue 595538 .

After discussion w/ dpapad@ we have decided to create a new issue that better describes the blocking behavior. Filed Issue 690138.

 Issue 608069  is very specific to search engines, so when it's fixed it will not address our concerns.

Matching priority of Issue 690138 on which this is blocked.

dpapad@: Is there any other way to cache icons in the history backend? For example, send some requests that fetch icons from the given URL, but don't visit the URL. During visiting page, Chrome save the icon somehow. Could we just emulate this code (i.e. only icon fetching)?

@kolos: Currently I only see references to ThumbnailDatabase from the history backend, see [1]. In theory we could:
 - Spawn a request to fetch a webpage URL
 - Parse the page and find the favicon URL for that page
 - Fetch the favicon itself and add an entry in the ThumbnailDatabase for it.

I don't know if making background requests to URLs that the user did not explicitly request is reasonable, (security team would have to chime in).

[1] https://cs.chromium.org/search/?q=history::ThumbnailDatabase&type=cs

Thanks dpapad@ for info. Year, background request might be not feasible. 

Did you investigate how bookmarks fetch icons? Seems like almost all icons works w/o explicit page visiting. 

I have not looked into Bookmarks. Adding tsergeant@ who has been involved with the new MD Bookmarks and might know.

@tsergeant: Do you know how bookmarks favicons are populated?

I think that the main way bookmarks favicons get populated when syncing a new profile is that the Bookmark sync node can contain the favicon URL and encoded image:

https://cs.chromium.org/chromium/src/components/sync/protocol/bookmark_specifics.proto?l=25

When the bookmark is synced, BookmarkChangeProcessor updates the FaviconService thumbnail database with the favicon bytes:

https://cs.chromium.org/chromium/src/components/sync_bookmarks/bookmark_change_processor.cc?dr=CSs&l=952

However, there's also a separate FaviconCache:

https://cs.chromium.org/chromium/src/components/sync_sessions/favicon_cache.h?l=60

which syncs a small number of favicons between devices. You can see the sync list for the current profile at chrome://sync-internals -> SyncNodeBrowser -> Favicon Images.

I'm not really sure how favicons end up in that cache (it seems like it evicts least recently used icons), but maybe it would be possible to ensure the favicons you need are in there.

+zea@, who might know more about favicon syncing.

The favicon cache icons are added when you visit the page. And yes, it has LRU eviction.

Honestly, favicon syncing just isn't something that works particularly well because there are too many different icon types in use across platforms. Android no longer even fetches web favicons.

I'd recommend triggering a fetch of the icon on the device that needs it, rather than relying on the icon already being there.  http://crbug.com/644102  describes a service that would enable such functionality.

tsergeant@, zea@: great thanks for your comments and useful links. I got to know much new stuff. 

Now I need to put it together and decide what way to implement. For now, my understanding is that we should user Google favicon service. Icons is not our main business. Could you kindly recommend a person how coordinates icons efforts in Chrome?

+Peter who is more familiar with the icon work going on.