spqchan@, do you know who can triage this bug related to zooming in on the bookmarks page?

CC tommycli@ also, as this has to do with the google search favicon, so he might have an idea what's going on here.

summary - can repro, I think the favicon service is returning a 1x icon for the 2x case for chrome://newtab?
Happy to dig further if needed. I'm not sure this is an omnibox bug but could be misaken if omnibox is populating the favicon cache wrong somehow.

-------
On M71 canary I got an ok scaling on Windows, but the favicon was a blank document rather than the G icon. Then I browsed around for a bit, tried to get Google entity suggestions, etc. And then I got the G icon and was able to repro.

The bookmarks manager's <div> for that icon:
<div id="icon" class="website-icon" style="background-image: -webkit-image-set(url(&quot;chrome://favicon/size/16@1x/chrome://newtab/&quot;) 1x, url(&quot;chrome://favicon/size/16@2x/chrome://newtab/&quot;) 2x);"></div>

is nearly identical to other icons:
<div id="icon" class="website-icon" style="background-image: -webkit-image-set(url(&quot;chrome://favicon/size/16@1x/[other_site_url]&quot;) 1x, url(&quot;chrome://favicon/size/16@2x/[other_site_url]&quot;) 2x);"></div>

and the actual .website-icon elements are sized correctly.

Applying the affected icon's <style> to an unaffected .website-icon repros it, so that narrows it down to the -webkit-image-set

Applying a webkit-image-set with only a 1x icon makes the problem go away, adding the 2x one, or having it be the only icon in the set, brings it back.

It looks like we're returning the same bits (or at least the same size) for 1x and 2x, but the 2x asset isn't any bigger:
a-1x) chrome://favicon/size/16@1x/chrome://newtab/
a-2x) chrome://favicon/size/16@2x/chrome://newtab/
b-1x) chrome://favicon/size/16@1x/http://www.google.com
b-2x) chrome://favicon/size/16@2x/http://www.google.com

On my setup, google.com's entry (b) returns a 2x image but the newtab page (a) does not.

CC a favicon owner for triage, per comment 3

***Mass UI Triage***

Hi,

Just to update:

Issue is still reproducible on Windows(7,8,8.1,10) and Linux(14.04) OS using Latest canary #72.0.3610.0

Please find the screen-cast for reference.

Could anyone please take a look in to this issue.

Thank You!

Deleted: Canary Behaviour.mp4 850 KB

	Canary Behaviour.mp4 850 KB View Download

I took a quick look although I'm not very familiar with the details here, pkotwicz@ may know better.

Wrt comment 3: chrome://favicon uses GetRawFaviconForPageURL() which is (according to the documentation) expected to return the closest available bitmap, without resampling.

The reason why it behaves differently for google.com (or any regular web page) seems to be that the codepath differs in FaviconServiceImpl::GetFaviconForPageURLImpl(), where native pages are treated differently. For the regular codepath, I think the key difference could be that HistoryBackend::GetFaviconsForURL() does some resampling (which is questionable).

My impression is that the UI shouldn't make assumptions about the size of the image returned by chrome://favicon.