Tested on Chrome Canary 64.0.3279.0, can't reproduce the issue.

Could you try again to see if there issue still exists on your device?

Same problem for me on canary.
One thing which I wasn't clear about: there's a homescreen icon but the splashscreen doesn't have an icon

Found the cause for this bug, seems it's a fault in the web manifest, not sure if we need to do something for it.

The width check fails so it goes to the no icon case
https://cs.chromium.org/chromium/src/chrome/android/java/src/org/chromium/chrome/browser/webapps/WebappSplashScreenController.java?l=220

displayIcon.getWidth() is 136, displayIcon.getWidth() is 137, minimiumSizeThreshold is 144

The icon specific in the website is https://www.olx.in/img/logo-192x192.png
the actual size is 181*183, but the size specific in web manifest is 192*192, so the icon is put in the xxxhdpi folder by the server

Android system resizes it to 136*137 (181/192*144=136, 183/192*144=137), which fails our minimiumSizeThreshold checks

see also: server details at http://b/70284394

For the sake of clarification, I believe that Android does this specific resizing because you were testing on an xxhdpi device

+mgiuca and +dominickn to comment since this deals with chrome's interpretation of web manifest spec

As far as I'm aware, there is no mention of splashscreens in the web app manifest spec.

The site has supplied 181x183px icon, but told us it's 192x192px. I guess we could apply a stricter check in the client and fail the installability check if the icon we fetch has dimensions that don't match those provided by the site. Thoughts?

This isn't really about slash screens, but is still a spec issue; specifically it deals with whether the spec is OK to have the "sizes" attribute in the manifest mismatch the actual size of the image.

I think it's somewhat unclear but I believe the manifest spec does not *require* that the bitmap images match the exact size given in the "sizes" attribute (in fact, the spec allows vector images which have no inherent pixel size). The only thing "sizes" is prescribed for is choosing the best from the list of images.

Therefore, we should not show a blank image. If the manifest says "sizes": "192x192" and a 181x183 image is served, then we should serve that image whenever 192x192 is the most appropriate image size. We shouldn't serve nothing just because the image isn't the promised size.

c#10: the manifest icon download process enforces a minimum size requirement (that is smaller than the ideal size we prefer). If the downloaded icon's actual size is smaller than the minimum, it gets thrown away and the icon download fails (content/browser/manifest/manifest_icon_downloader.cc).

I don't particularly like the idea of serving images that we know won't look good. If it says "sizes": "192x192" and we get a 1x1 image, should we serve that? It's definitely not meeting the quality bar we want to promote.

I suppose independent of the manifest check, we could impose our own quality bar for splash screen images in particular. (There is nothing in the manifest spec that requires us to render a splash screen.)

Otherwise, should I file a bug to see if we should add a requirement to the manifest?

I feel like situations such as this are most often errors, and we should inform developers upfront (e.g. as part of Lighthouse and as a console warning when triggering the banner flow via devtools). Spec'ing that the icon size should match the actual size of the icon downloaded seems sensible to me if we can avoid the oft-triggered density / physical vs logical size debate.

Checking the physical size alongside the manifest-specified size as part of our flow should be straightforward. We can roll it in with work to allow SVG icons as well as PNG which I'd like to see done sometime in Q1.

Thanks, guys. #13 sgtm. Could we prioritize the lighthouse part of this ahead since the earlier we get it in front of devs, the better? That's going to have more reach than our console logging and strictness checking. Also per Sam's document on communicating policy, I think that it makes sense to get it out.
 
At the end of the day, as a user, the current situation really isn't good UX and I'd personally prefer a small icon to non at all.