Follow up work on Issue 798029 will help in the case where HTTP isn't the right scheme (by adding hostname-based fallback queries to the favicon service)

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

commit a7d072a5ce09b98e104ba7240cd61bcc9554258f
Author: Dominick Ng <dominickn@chromium.org>
Date: Mon Jan 08 00:41:55 2018

Fix broken favicon fetching for chrome://settings/siteData.

chrome://settings/siteData currently never ever shows proper favicons
for any site. The problem is that URLs on the page are listed without
schemes as site data is commonly hostname-bound. The scheme-less URL is
eventually passed to the WebUI FaviconSource, where it fails to parse
into a GURL, leading to a request to the Favicon Service for a favicon
for an empty URL. This request obviously fails and hence
chrome://settings/siteData never gets any favicons.

The fix is to always attach a scheme to the URL (defaulting to HTTP) if
one isn't there. Future work will update the Favicon Service to allow
hostname-bound querying, which will further improve the number of icons
fetched and displayed on this page.

BUG= 798028 

Cq-Include-Trybots: master.tryserver.chromium.linux:closure_compilation
Change-Id: I76c3fb0e921962618a5782c0559a1d6f334fd0bc
Reviewed-on: https://chromium-review.googlesource.com/846479
Reviewed-by: Dave Schuyler <dschuyler@chromium.org>
Commit-Queue: Dominick Ng <dominickn@chromium.org>
Cr-Commit-Position: refs/heads/master@{#527551}
[modify] https://crrev.com/a7d072a5ce09b98e104ba7240cd61bcc9554258f/chrome/browser/resources/settings/site_settings/site_data.js

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

commit 4c85aa1da711a621de1fcd62ca6d80ee6cea5e07
Author: Dominick Ng <dominickn@chromium.org>
Date: Tue Jan 09 23:02:17 2018

Don't query the thumbnail database with an invalid URL.

Querying the thumbnail database with an invalid URL will always fail.
This CL pre-emptively returns the default icon if an invalid URL (e.g.
the empty URL, or the JavaScript "undefined") is queried from
chrome://favicon, avoiding the round-trip to the thumbnail database.

BUG= 798028 

Change-Id: I3f42d74f80a1585786093371270551e13bd6d264
Reviewed-on: https://chromium-review.googlesource.com/855278
Reviewed-by: Dave Schuyler <dschuyler@chromium.org>
Commit-Queue: Dominick Ng <dominickn@chromium.org>
Cr-Commit-Position: refs/heads/master@{#528155}
[modify] https://crrev.com/4c85aa1da711a621de1fcd62ca6d80ee6cea5e07/chrome/browser/ui/webui/favicon_source.cc

Tested this issue on Mac OS 10.12.6 using chrome latest canary #65.0.3318.0 by following steps mentioned in the original comment. After opening few sites like facebook, yahoo, youtube and twitter observed only few favicons are displayed and remaining still seen blank.

dominickn@ Attaching screen shot for reference, could you please confirm is this is the expected behavior of the issue? 

Deleted: Screen Shot 2018-01-11 at 5.46.37 PM.png 46.3 KB

	Screen Shot 2018-01-11 at 5.46.37 PM.png 46.3 KB View Download

It is expected that not all of the listings will have icons. In particular, domains like "youtube.com" and "twitter.com" will have mappings in the favicon database for "www.youtube.com" and "www.twitter.com".

Getting icons on these sites will require some significant changes in the backend favicon database. I think we've done as good as we can with simple fixes and any more will require quite a bit of additional complexity, which may or may not be okay with the favicon owners.

This is probably as much as we can do for now. The remaining cases are ones like:

1. visited www.google.com, and it sets a cookie for all of google.com
2. chrome://settings/siteData has an entry for google.com, which has no favicon because the user has not visited google.com (only www.google.com)

Fixing this is going to need some work in the backend - we'd probably need to store hostnames in the favicon icon mapping database, and then elide certain schemes like m. or www. when querying.

I think an easier solution is to try and group the list by domain, and then the top-level domain can pick an icon from all of the subdomains/origins within it. That won't require backend changes since it's purely in the UI layer. I'll be pursing this approach with the redesign of chrome://settings/content, and perhaps this will pick it up as well during the project.

As per comment #5 adding verified label for M65.

Thanks!