Just to make sure it's clear: there is no errors in m.oumy.com manifest. Same thing happens to all apps, e.g. Google+ or I/O 2016, all have small icons:

Deleted: CigmDBnVAAAcfYg.jpg 79.6 KB

	CigmDBnVAAAcfYg.jpg 79.6 KB View Download

Dom: you want to take a pass at this?

Thanks for reporting this issue.

I've managed to reproduce this inconsistency on a Nexus 7. However, I see the icon from https://html5.oumy.com:8080 being small (and with rounded corners), and the icon from https://m.oumy.com/ being larger. I think the inconsistency in which icon is larger vs smaller depends on the device and its scale factor. The Android launcher also does its own padding and resizing, which we have no control over.

I'm pretty sure that the size difference and the rounded vs. non-rounded corners are because an icon that isn't specified in the manifest goes through an additional padding + rounding process that manifest icons don't go through.

Another side issue is that I notice the manifest version chooses a 96x96px icon (the smallest icon which is large enough). The icon is slightly less sharp than the <link rel="icon"> version, which is forced to pick the 192x192px icon. However, this is working as intended.

I think the best way to solve the size inconsistency is to make manifest icons go through the same clipping + rounding process as favicons. That ensures that the icons should be the same dimensions and look right. dfalcantara@, WDYT? I have a proposed fix at crrev.com/1997313002.

Clarification: the reproduction in #4 was on a Nexus 9, not a Nexus 7.

I guess we have to ask some of DevRel team if it's fine to round all icons for home screen. It probably won't affect circled images, but may affect some precompiled icons, e.g. with already rounded corners.

Main issue here is that icons from manifest aren't consistent with other apps' icons in size. I understand that custom/OEM launchers make things much complicated here. Hope there is a way to fix this.

As pointed in comment 6, the rounding has consequences. I would prefer not to do the padding+rounding for Manifest icons unless we have strong reasons to do it.

However, I'm not sure if I follow: the Manifest icon (from m.oumy.com) shouldn't have any padding added but ends up smaller than the <link rel> icon (from html5.oumy.com) with padding? That sounds odd. Dominick, can you explain why?

#7: the icons are different sizes. For the manifest icon, the smallest icon larger than the required size is used. On my Nexus 9, that's the 96x96px icon. However, for the favicon, it's resized to a maximum of 1.25 * getLauncherLargeIconSize() before adding the padding. That's 144px * 1.25 = 180px on the Nexus 9. Then 2 / 44 * 180 = 8px of padding is added on either side, resulting in a 196px icon. Then it looks like the launcher resizes the icon down slightly when displaying it, resulting in the favicon-is-smaller-than-manifest-icon that I see on the Nexus 9.

My guess is that the Galaxy Tab launcher resizes in a different way, which combined with the platform-specific calculation of the Chromium-side icon resize results in the opposite behaviour.

There are two issues here:
 1. manifest icons and favicons appear at different sizes on the homescreen
 2. depending on the particular icon sizes we give to the launcher, either leaving the size unchanged (Galaxy Tab A) or resizing (Nexus 9) results in an icon that's smaller than desired.

Issue 1 is addressed by ensuring we do the same resizing to manifest icons and favicons. I think  issue 2  is caused by the Android launcher doing what it likes with the icon sizes it's given, so I don't know if we can really address it.

mlamouri@: do you have thoughts on comment 8?

Hmm, sorry, I thought I replied to that. My understanding from the bug report was that the icon coming from the Manifest is smaller than the one coming from the favicon. That's the other way around?

The behaviour that you describe on your N9 seems to be working an intended: the Manifest icon is bigger than the favicon because we don't add a padding to the icon. I think adding a padding would be a bug in this case.

Yes, on Galaxy Tab A manifest icons are smaller then <link> icon.

My guess is that 192x192 image from <link> is passed as is to Tab's
launcher, so it resizes image to 64 (or whatever size it uses).

But with manifest, 48x48 (device's pixel density is 1) image is picked by
Chrome and passed to the launcher as is, so it ends up smaller then
launchers standard/apps icons.

Manifest icon and favicon don't use the same target homescreen size and I think the manifest one has a bug. It uses getIdealHomescreenIconSizeInDp which ends up using a predefined value. I wonder if it should use https://developer.android.com/reference/android/app/ActivityManager.html#getLauncherLargeIconSize() instead like the favicon code seems to use.

So you're suggesting that the resolution is:

1. Icons from the manifest should be larger than from the favicon
2. The manifest icon selector should be using getLauncherLargeSize like the favicon code to ensure that a similarly large base icon is selected

I still feel that we should be doing exactly the same thing for icons from either source. If we don't want to round the corners of manifest icons, can we stop doing it for favicons?

We tried to stop doing the rounding of icons and UX refused. Feel free to try again :)

+cc rolfe@ and +sgabriel@

Issue 530329 adds padding and rounding the corners of homescreen shortcut icons for sites that don't have a manifest (e.g. icon is the favicon or specified in the page head).

If the developer has supplied a manifest *and* Chrome decides to use an icon from that manifest, the added to homescreen icon does not have this padding or rounding: it is simply used as-is, which is apparently WAI. That leads to the inconsistency described in this issue, where otherwise identical icons depending on whether they are specified in the manifest or in the favicon / link rel.

Can we do something consistent between the two? E.g. not applying the rounding and padding to favicons, or do that to manifest icons?

Just for the record, if you still need a repro, use https://dev-m.oumy.com/ instead of https://m.oumy.com/ because it's disabled right now.

It's definitely a visual designer question!

Will remove sgabriel@ from this thread - current focus is now CrOS. But I can run this by the new VisD owner bettes@ mid next month if it can wait. (bettes is on holiday)

Talked with +bettes and naturally we designers want the Impossible Thing. Would be great if icons consistently were correctly sized to match other app icons and, per Material visual standards (https://material.google.com/style/icons.html#icons-product-icons) rounded.

This sounds like it may be controversial as it means clipping manifest icons. Is there someone we should discuss this with to make sure we're all in agreement?

+ bettes for realz

Owen, at least.

Thanks! If mlamouri@ and owencm@ (and any other Important People) agree, crrev.com/1997313002 does exactly what the designers want, and clips/pads manifest icons the same way as favicons.

The manifest icons used to be clipped and padded in that way, but we disabled that a year ago when a web developer (flipboard I think) complained that their icon is supposed to be square and they didn't want the clipping.

We ended up settling on the fact that it's good for developers to have control here. That said if we see many instances of square icons then this may be worth revisiting (although I haven't seen that problem).

Is it possible to resolve the issue of the icons being too small without applying the clipping?

I can remove the rounding of corners and just apply the padding, which should make the icons the same size at least (favicons vs manifest icons). But that should go back to the designers for their opinion.

I've cc'd Rebecca on the thread from a year ago about the feature for her context.

And for the sakes of this thread, here's a quote from an external developer about the clipping: "[Due to the A2HS banners showing up with a wrongly-rounded icon] I don't know if we would want to ship service worker support until we can ensure our app icon is not being rounded by the system."

I think mostly bettes@ and I would just want to choose the thing that looks the best and makes the least number of developers unhappy. We don't always have to follow Material but it is a useful guideline for the system as a whole (in principle every app/site is prepared for their icon to be cornered if need be so the home screen looks uniform.) 

If we don't crop our own A2HS shortcuts will that mean everything is at least sized properly, even if the edges aren't rounded? (And Alan - could you live in that world?)

If someone will want to make rounded icons with a shadow (as per Android
guidelines, I believe), them one won't be able to do so with auto-rounding.

Offline discussions with bettes@ and owencm@. Bettes@ said:

"I regard rounded corners as important for the polish of our OS ecosystem, but i can't envision a scalable system that keeps polish while honoring third-party brand standards. So if that means removing our constraints, that's fine with me."

Good to have a resolution here! I'll amend crrev.com/1997313002 to remove the corner rounding, but preserve the padding. That should ensure that manifest vs favicons should be the same size, and neither will have rounded corners.

What's the rationale to add padding for icons coming from the Manifest? The reason why we add padding for icons coming from the favicons is that they are meant to be displayed on a very small surface (tab strip) so they usually do not have padding. Do we want to assume that Manifest also have no padding? If they do, they will look ridiculously small.

Maybe we could check what would happen on some popular added to homescreen websites -- check if the change would improve or reduce the native look of the icon.

The padding added is quite minimal - see the attached screenshot of the Nexus 5 between the no-padded and padded icons.

Deleted: Screenshot_20160718-214258.png 2.6 MB

	Screenshot_20160718-214258.png 2.6 MB View Download

Could you show the apps alongside other apps installed from Play? I think we'd want the icon to be the same size/shape as other apps. Perhaps we add padding because otherwise they'd be too large?

Here is is next to the Chrome Dev/Beta logos. The non-padded version is definitely much too big.

I really want the behaviour to be consistent between all icon sources - I think it's just confusing if one way uses padding and the other doesn't because it's basically undocumented.

Deleted: Screenshot_20160720-113018.png 2.5 MB

	Screenshot_20160720-113018.png 2.5 MB View Download

Thanks for making that mock! Really helpful. Seems best to pad consistently so that every link is both treated the same and fits in with the Android app home screen ecosystem.

The reason why non-padded icon is too big is because most Play Store icons itself has padding made by icons designers.

The original issue is about manifest icons **being too small**, not being too big. Does padding solve **too small** problem?

mlamouri: I've attached another screenshot comparing before and after for various PWAs. The top icon is with my change, and the bottom is Chrome stable. WDYT?

nekr: Part of the problem here is that there is an inconsistency in the way the icons are treated (padding/no padding). I first want to try and remove that inconsistency. The second issue is that the way manifest icons are selected (the smallest icon larger than the required size) is different to how favicons are selected (biggest possible), so the raw icon source is different.

Next after making sure we do the same thing with both icon sources is trying to unify how the icons end up being selected, which should eliminate the you-see-them-smaller-I-see-them-bigger problem. This is slightly more complicated, because there are a few other things in Chrome which use a similar manifest icon selection algorithm (e.g. app install banners), and I'd like to make all of them work the same. This ties into some wider refactoring that I'm doing. Sorry if it seems like the focus is away from the original issue - we're getting there!

Deleted: Screenshot_20160722-154516.png 2.4 MB

	Screenshot_20160722-154516.png 2.4 MB View Download

It looks like it makes the Flipkart icon a bit smaller than the Chrome icon. Is that correct? I wonder if we could implement a simple heuristic and check if the pixels on the border are pure alpha and if they are, we add a padding. I think this should serve the purpose of resizing the huge square favicon but would prevent us from resizing icons that already have a padding. WDYT Dominick?

#38: I guess that would work. My main goal is to ensure that whatever we do, it's the same between manifest and favicons all the way through the stack - so given two identical icons, we should end up with exactly the same icon on the homescreen. I'll see if I have time to implement that this week. 

dominickn: Thanks for the explanation.

The idea of doing some heuristics based on icon transparent edges sounds good to me.

@mlamouri: I had a play around with this today. It turns out that Flipkart and SVGOMG's icons both contain non-pure alpha pixels at the centre of each border. Flipkart's icon has only a very small alpha value at these spots (max ~20), whereas SVGOMG has an icon which actually does run right to the border. The corners for both icons have alpha = 0 for full transparency.

We could just check the corners with the heuristic (say, everything except ~20 pixels or so in the centre), but I wonder whether this is getting a bit too magical now. I originally wanted consistent behaviour, and this is starting to creep away a bit.

mlamouri/rolfe: any further thoughts on #41?

To summarise my point of view: I don't think we should automatically resize icons from the Manifest because they might end up too small. This is also the original issue this bug was abbout as pointed in #35 by OP :) If we had to have one common path with heuristics, I would say that we should never touch the icons: I feel more confident to have sub-optimal (too big) favicons on the homescreen compared to sub-optiomal manifest icons (too small) in there.

This said, I would be okay with a heuristic that only resize the square icons that take 100% of the space: we could check the four corners pxiels and if all four are not transparent, we would resize.

Anything to make the icons match native app sizing works for me. (Blend in with the ecosystem as much as possible, not look like an error, etc.) I like mlamouri's proposal to resize the ones that need it. Understand this could be tough though.

I'll try the corners-only heuristic and see how that performs.

Attached is a sample with the corners-transparent heuristic: the top row is with the heuristic, and the bottom row is without. Notice that the round icon / icons with rounded corners aren't padded, while the full square icons are resized. I think this is a fairly nice compromise.

mlamouri@, if you're okay with this, I'll land the patch, then start investigating the icon selection heuristic to see if everything can use getLauncherLargeIconSize() or thereabouts.

Deleted: Screenshot_20160810-163354.png 2.6 MB

	Screenshot_20160810-163354.png 2.6 MB View Download

Oops, by "resized" I meant "padded" in comment #46.

dominickn@, I suggested it so yes, I'm fine with you landing this change :) Feel free to send a review my way.

And thanks for your patience! I like the end result so hopefully, the discussions were useful.

Great! Sent the review your way for crrev.com/1997313002. Happy to be making sure that we're doing the right thing by everyone. :)

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

commit 96548fc8973a2e1fa7616d2de7fca20cbe5c98b6
Author: dominickn <dominickn@chromium.org>
Date: Fri Aug 12 00:51:48 2016

Make favicon and manifest icon processing more consistent for add to homescreen.

Manifest icons are used as-provided for add to homescreen on Android,
while favicons are processed to add rounded corners and padding.
This leads to inconsistent icon sizing when a site uses a manifest to
declare icons versus using <link rel="icon"> or favicons.

This CL is a first step in addressing the inconsistency by ensuring both
favicons and manifest icons are processed identically for add to
homescreen. The corner rounding is removed completely, while the
padding process is changed to only be applied on icons which have
nontransparent (alpha != 0) pixels in all four of their corners from either
source. This heuristic attempts to detect square icons with no existing
padding, which is often how favicons are produced. If any transparent
pixel in any corner is detected, no padding is applied.

A future CL will make the icon selection heuristic consistent between
favicons and manifest icons, which will complete the fix for this issue.

BUG=612028

Review-Url: https://codereview.chromium.org/1997313002
Cr-Commit-Position: refs/heads/master@{#411494}

[modify] https://crrev.com/96548fc8973a2e1fa7616d2de7fca20cbe5c98b6/chrome/android/java/src/org/chromium/chrome/browser/ShortcutHelper.java
[modify] https://crrev.com/96548fc8973a2e1fa7616d2de7fca20cbe5c98b6/chrome/browser/android/webapps/add_to_homescreen_data_fetcher.cc
[modify] https://crrev.com/96548fc8973a2e1fa7616d2de7fca20cbe5c98b6/chrome/browser/android/webapps/add_to_homescreen_data_fetcher.h

 Issue 689170  has been merged into this issue.

Removing myself. If you still need design input, reach out to chowse@ as the primary web platform contact