This will be difficult to debug with the information provided. Maybe try pressing F12, click console, and see if there's any errors in there?

Possibly https://dev.chromium.org/for-testers/providing-network-details could be useful, too.

This appears to be a duplicate of 633683.

What kind of images? How are they served? The fact we now have 2 reports should help us work this out.

I have this problem on multiple machines with Windows and Linux after updating Chrome to version 52.

First identified the problem in Zimbra Web Client. But then randomly experienced in other services (eg Feedly)

As a rule the images do not load. But if you reload the page several times, time image appears, time disappears. 

Checking the HTTP headers in development mode when the issue occurs, the headers requests and responses are exactly the same, with changes only the time stamp.

Here is a direct connection to the server without proxy and without firewalls.

Tested in canary and also happened the problem.

Tests from my another post about this in Google Chrome Help Forum:

1. Does the issue persist in incognito mode?
R: Yes, persist.
2. Clearing cache and cookies can be useful.
R: The incognito mode is no longer a session without cookies and cache? Anyway, the issue persists.
3. Uncheck Use hardware acceleration (Menu> Settings> Show Advanced Settings > System menu).
R: Done and the issue persists.
4. Try resetting the Chrome browser to see if that helps.
R: I reset and the problem persits.
5. Also, creating a new user profile on your Chrome can be helpful.
R: I created a new profile, and the problem persists.

Unfortunately the URL of images where this problem occurs on my network are in a restricted environment. But it can be tested with the following image I found searching on Google:

Open in incognito mode:

https://mail.myaccess.ca:7071/zimbraAdmin/skins/carbon/logos/LoginBanner.png

Press F5 to reload, shift+F5, ctrl+F5 or add dummy parameters at the end of the url like this:

https://mail.myaccess.ca:7071/zimbraAdmin/skins/carbon/logos/LoginBanner.png?asdf
https://mail.myaccess.ca:7071/zimbraAdmin/skins/carbon/logos/LoginBanner.png?qwert

And press enter, then try reloading several times.

In M54 linux I'm seeing the initial load in an incognito window show a little square in the top left, which I assume is the error image. Reload causes the image to appear. At least we can reproduce it now, I suppose.

Bisectors, could we try to figure out where between m51 and m52 this failed?

Thanks for the very helpful info! Based on that URL I bisected to:

https://chromium.googlesource.com/chromium/src/+log/f8563372f7ba26f49ea5b4f9fcff0ef4a5a5ac68..7c8b702e187b1fefdd6bf9dfd9aaa303dddfdc5a

d2234904faee943bd987bd38d620096db808efca looks most likely out of those.

Once that patch is confirmed as the cause we need to get this merged all the way back to stable, I think.

Unfortunately this is not going to be a clean revert, due to the changes that have gone in on top of it. I get a boatload of conflicts reverting on trunk.

I'm trying to revert in trunk, but there have been some deep reaching changes, such as OwnPtr -> std::unique_ptr conversion. Annoyingly, and revert will need to be done for each branch separately. It would be good to know why this is failing only on some specific cases, so I'll probably try to figure that out too once I confirm a revert fixes things.

This is a paint-team m52 regression. A note to help us track such things.

I've given up on reverting the change. Too much has been piled on top.

If you start chrome in incognito mode it always fails. Not in incognito and cached data causes it to draw first frame. When it doesn't draw, DecodingImageGenerator::onRefEncodedData and onGetPixels are never called, so the problem is upstream from there. Continuing to investigate.

scroggo@ will be out all week; somebody else ought to own initial response if this is a P1 in stable. +fmalita@ to help triage.

I think I see the issue: ImageDecoder::determineImageType uses a single SharedBuffer::getSomeData call to fetch the image signature - but this call respects segmentation, and the signature is not guaranteed to be in a contiguous segment.

So if the first bytes of the image are fragmented, we never get to detect it as valid.

Hi 

Just an update team regarding the debugging which I did.
Already tried checking the network mode and the web server response which we are getting is proper 200 which has been described in ticket 633683. The request/response HTTP headers are same for both images i.e. the image which has an issue vs the image which is coming fine.Problem started with 52 version and persist in the v53 also.


Thanks,
Ratan 

An update on this issue ...

We have a patch in the final stages of preparation that will fix this issue, and we'll then try to merge it all the way back to m52. Expect that to take a few days due to all the change that has happened since.

We appreciate the work you all put into finding a reproduction case and investigating possible causes. If possible, could you please start using the beta channel so that you will hit issues sooner, which results in fixes while they are easier to do and before millions of users see the problem? Beta is your early warning system for changes that we are making to the platform, and it is generally as stable as stable (most Chrome developers use Beta versions as our primary browser, or even Canary).

 Issue 633683  has been merged into this issue.

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

commit 1b80a74055acae8a0296afe644513f52e34dec79
Author: fmalita <fmalita@chromium.org>
Date: Wed Aug 17 20:56:39 2016

Fix fragmented image signature handling

ImageDecoder::determineImageType() is currently only examining the first
buffer segment (getSomeData).  But the signature is not guaranteed to be contiguous,
nor do we ever re-consolidate the buffer after receiving more data.

As a consequence, when the signature is fragmented (e.g. due to a slow
image load), we cannot detect the image type - even after all the data is
later received.

Refactor determineImageType() to consolidate the signature when needed.

BUG= 637556 
R=pkasting@chromium.org,scroggo@chromium.org,schenney@chromium.org

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

[modify] https://crrev.com/1b80a74055acae8a0296afe644513f52e34dec79/third_party/WebKit/Source/platform/graphics/DeferredImageDecoderTestWoPlatform.cpp
[modify] https://crrev.com/1b80a74055acae8a0296afe644513f52e34dec79/third_party/WebKit/Source/platform/image-decoders/ImageDecoder.cpp

Merge request, right? Let's start with 53.

Your change meets the bar and is auto-approved for M53 (branch: 2785)

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

commit 560b2ab7f31013f1a0ad9f0c174cb1ccd267e132
Author: Florin Malita <fmalita@chromium.org>
Date: Fri Aug 19 00:00:55 2016

Fix fragmented image signature handling

ImageDecoder::determineImageType() is currently only examining the first
buffer segment (getSomeData).  But the signature is not guaranteed to be contiguous,
nor do we ever re-consolidate the buffer after receiving more data.

As a consequence, when the signature is fragmented (e.g. due to a slow
image load), we cannot detect the image type - even after all the data is
later received.

Refactor determineImageType() to consolidate the signature when needed.

BUG= 637556 
R=pkasting@chromium.org,scroggo@chromium.org,schenney@chromium.org

Review-Url: https://codereview.chromium.org/2252723003
Cr-Commit-Position: refs/heads/master@{#412631}
(cherry picked from commit 1b80a74055acae8a0296afe644513f52e34dec79)

Review URL: https://codereview.chromium.org/2260703002 .

Cr-Commit-Position: refs/branch-heads/2785@{#674}
Cr-Branched-From: 68623971be0cfc492a2cb0427d7f478e7b214c24-refs/heads/master@{#403382}

[modify] https://crrev.com/560b2ab7f31013f1a0ad9f0c174cb1ccd267e132/third_party/WebKit/Source/platform/image-decoders/ImageDecoder.cpp

Hi Thank you so much.  It's easier to reproduce the issue if you have an
Apache HTTP server 2.2 (We use Oracle HTTP Server in front of our Oracle
Fusion Middleware SOA platform)
SetEnvIfNoCase Request_URI \
\.(?:gif|jpe?g|png)$ no-gzip dont-vary

Thank you so much.
Pedro B. Morales

Let's try to push this to stable also.

No M52 release is plan at this point as we're getting closer to M53 stable promotion. Please let me know if there is any concern here. Thank you.

Are we talking days or weeks expected for M53 stable?

If "days" I think it's fine. A reload of the page fixes the issue in many cases and I suspect most people would do that when faced with a missing image.

In my case even the page reload did not help and the images were not getting rendered even after multiple tries. When can I expect the stable version m53 for actual comsumption which will resolve this issue ?

We can never be sure when a specific version will be promoted to the stable channel, but it's very likely to be well under a month. We decided not to push a refresh of M52 for this issue given the timeline and existing impact and potentially negative impact of pushing out a new version.

Internally we investigate the test failures that led to this stable channel regression and look at our triage and bug fix process to see where improvement is possible.

Can someone help me understand what triggers this bug, in a couple sentences or less?  If this is a global issue it seems like it'd warrant an immediate respin (and we would have caught it sooner) so it'd be good to know what percentage of our users are experiencing this.

fmalita may correct me, but I believe it is triggered when a server delivers image content in small chunks for whatever reason. It seems to be related to server configuration in some way, as suggested by comment #22 (I'm no server expert).

Given the vast number of images Chrome loads, plus the fact this wasn't found in the Beta period, makes me think the impact is quite limited. We've seen 3 developers interacting on this bug (thanks everyone for the help and patience).

OK; if impact is limited only to servers with a configuration that we think is far outside the norm, then we can wait for M53.  If we have evidence this is happening more frequently though please let me know and we can consider an M52 respin, though I'd be quite hesitant given the fact that lots of code has moved underneath the original root cause of this issue.

FWIW I agree this sucks, and I'm really sorry for anyone experiencing this issue; unfortunately any respin carries risk (more in this case given the above) and we might end up making things much worse for billions of users.

I've spent a lot of time with the problem and can confirm that, for me, here is how to reproduce it:

0. Start with Chrome v.52. Chrome Canary v.54 is not exhibiting the behavior.

1. Clear your browser cache.

2. Request a "large" graphic from an Apache 2.2.3 CentOS web server. "Large" in my case is ~100K. For me, this problem does not happen when hitting an Apache 2.2.15 CentOS web server. It also does not happen for "small" (file size) images.

3. If you now simply Refresh (F5), the image will show up. I believe this is because the image IS in cache, and delivers from there.

4. If you now disable cache (Developer Tools > Network > Disable cache) and re-request the image via a simple refresh (F5), the problem happens.

5. I can also make the problem happen if I clear cache and add throttling.

Thanks for working the issue. This started affecting us the moment v.52 arrived. 

[1] this is server response for failure:

HTTP/1.1 200 OK
Date: Tue, 23 Aug 2016 15:57:50 GMT
Server: Apache/2.2.3 (CentOS)
X-Content-Type-Options: nosniff
Last-Modified: Mon, 06 Jul 2015 22:28:20 GMT
Content-Length: 84730
Connection: close
Content-Type: image/jpeg

Since Chrome 54 has fixed it, additional reproductions are no longer needed. Chrome 53 will fix it, which should be released in about two weeks.
You can see release date estimations at https://www.chromium.org/developers/calendar

Tested the issue on windows 7, Linux Ubuntu 14.04 and Mac 10.11.6 using chrome version 53.0.2785.80 with the below steps

1.Opened the URL https://mail.myaccess.ca:7071/zimbraAdmin/skins/carbon/logos/LoginBanner.png in incognito mode
2.Reload(F5) , shift+F5, ctrl+F and added dummy parameters at the end of URL
3.able to see the square box for few seconds at initial load of the page and then changed to image.
 
In reported version (52.0.2743.116) am seeing that the square box stays like that when used shift+F5, ctrl+F5. it is not changing to image.
 
fmalita@ Please find the attached screen cast and confirm the behavior to verify the issue from our end..

Thanks,

Deleted: 637556.mp4 873 KB

	637556.mp4 873 KB View Download

@kawaru thanks for verifying, that is expected: the issue is fixed in M53 and later.

Thanks for the quick update. Adding TE-Verified labels.

Hi Team 

So When can we expect the m53 for actual consumption ? Any tentative dates ? 
I checked the release calendar and as pet the plan it will be there on Sep 6. Is this true ? Please confirm.

Thanks,
Ratan

This is the estimation, yes.