Thanks for filing the issue!

Able to reproduce the issue on reported chrome version 66.0.3359.181 and on the latest canary 68.0.3436.0 using Ubuntu 14.04, Mac 10.13.1 and Windows 10. As the issue is not seen in M60, hence providing the bisect info.

Bisect Information:
===================
Last Good Build: 65.0.3318.0
First Bad Build: 65.0.3319.0

You are probably looking for a change made after 528649 (known good), but no later than 528650 (first known bad).
CHANGELOG URL:
 https://chromium.googlesource.com/chromium/src/+log/cc43f5c62e8bd7b3964bffd99871fa0843a415b0..eab1ec606de5921ae4e78ce5ce690076e0a37a71
Suspecting: https://chromium.googlesource.com/chromium/src/+/eab1ec606de5921ae4e78ce5ce690076e0a37a71
Review URL: https://chromium-review.googlesource.com/860498

@Stephen Chenney: Please help in assigning it to the right owner if this is not related to your change.

This is tricky. The best solution is probably to change the page background color based on the image color. i.e. very dark images get a light page background for contrast. I'll see what I can do.

And if there was a hairline white stroke around the black?

We could choose to show transparent as an opaque checkerboard, but that has its own downsides and I think is worse on net for the sorts of things people do with looking at images in browsers.  In the end a browser is not an image viewer, and I expect it to fall down sometimes.  I would WontFix this.

I certainly agree that no matter what we do there's a way to confound it. I'll think some more but my proposal may well be to WontFix.

Please don't WontFix. We're not talking about "a way to confound it," we're talking about a simple black-on-transparent image. This is a common-enough case that Chrome should handle it properly. Moreover, doing a Google image search for "transparent background images", all of the black-on-transparent images I found have the same problem.

Examples:
http://diylogodesigns.com/blog/wp-content/uploads/2016/05/adidas-new-logo-Transparent-Background.png
https://sguru.org/wp-content/uploads/2018/02/amazon-icon-logo-5D44CF81DD-seeklogo.com_.png
https://www.pngarts.com/files/1/Masjid-PNG-Image-with-Transparent-Background.png
https://cdn.shopify.com/s/files/1/1769/1685/files/BD_Clipping_path-03_180x.png?v=1525021368

If you get a more general algorithm that still fails in some unusual cases, then it seems okay to WontFix the remaining edge cases. But black-on-transparent is not really an edge case, especially when, as with the original example, the png itself declares its background color to be white.

And in our old UI, white-on-transparent images would fail.  And if we dynamically change the background color for images that appear to be dark, there's all kinds of problems that arise, e.g. misdetecting the color and "user assumes image is whole screen size because the page is not showing any of the dark grey background color", besides the cost of writing, testing, and maintaining such an algorithm.

The reason I propose WontFix is not that it's unreasonable to have a black-on-transparent image -- you can certainly find them if you try, just as you can find almost any other kind of image if you try -- but because the browser is trying to optimize for a reasonable presentation of most images without taking on the burden of being a full-fledged image viewer, which isn't what we should be spending our time engineering.

Google Drive shows the checkerboard for transparency. Google Photos matches Chrome's behavior (in fact it's worse because the background is totally black).

Black on transparent does seem like a plausible image but almost exclusively as an input into other image operations. That is, you put it on top of another image, or use it as a mask, clip or filtering input. pkasting@ is completely right that we are not an image viewing and manipulation system.

I would argue that going with a less dark grey background might be a decent approach. Yes, it could be confounded, but all black is more common I think than all dark grey.

The reason we changed from a lighter color to a darker one before was to focus the user more on the image and have it be more immersive/less blended into the page content.  It increased the contrast with the common case.

I just hit this on one of our docs:
https://cs.chromium.org/codesearch/f/chromium/src/third_party/blink/renderer/core/layout/doc/ltr-tb-scroll.png

I helped the UX team when they originally added the checkerboard transparency feature (http://crrev.com/429820, see also https://docs.google.com/document/d/1wJPz4kn-9mEFs_ZEM0hAwwr-YzBdW-5hdX1-jkt81Ng/edit), and was on leave when it was removed.

I think we should re-add cherboarding for transparent images. Google drive shows the checkerboard for transparency. Google images does too. The reason google photos doesn't is that it's meant for photos. I only have anecdotal evidence but I think black-on-transparent is more common than white-on-transparent.

Recently I switched from Firefox to Chrome, and I immediately ran into this problem. https://i.imgur.com/Q3SbG87.png Surely Chrome developers use their own software and must have noticed this? I've been using Chrome for less than a day and as a web developer, this makes Chrome almost unusable for me. Also, how can this be a ticket be created in May this year? Really, nobody ever had any problems with this? I'm truly flabbergasted.

I'd be OK with putting the checkerboard behind just the image itself.

Given that, sometime this week I"ll make the change.

 Issue 911897  has been merged into this issue.