Note sure if this is a Blink or Network issue. Adding both components.

Almost certainly a Blink issue.

The markup seems buggy (an extra comma means that the medium.png image is considered as a 1x image) Either way, I'm having trouble reproducing this. Could you put up a simple test case that shows the issue?

Ah sorry the extra "," is a typo and does not belong there.

Below is an image that has a small doll image and then a larger logo. Interestingly they do not exhibit the odd behavior in codepen OR when I use them from their original locations locally. However hosting them locally from my (jekyll) dev server causes the behaviour to show up. I tried using non relative local url as well but that did not seem to change anything.

-- THIS WORKS --
<img src="http://www.bumpybelly.com/media/catalog/product/cache/1/image/9df78eab33525d08d6e5fb8d27136e95/1/4/1427281176_60093and10-04andaandonesize_w0_h457_dope.png"
sizes="100vw"
srcset="http://www.bumpybelly.com/media/catalog/product/cache/1/image/9df78eab33525d08d6e5fb8d27136e95/1/4/1427281176_60093and10-04andaandonesize_w0_h457_dope.png 457w, https://upload.wikimedia.org/wikipedia/en/thumb/5/5c/Big_Time_Rush_logo.svg/1280px-Big_Time_Rush_logo.svg.png 1280w"
alt="">

Deleted: locally hosted.png 324 KB

	locally hosted.png 324 KB View Download

Deleted: locally hosted 2.png 191 KB

	locally hosted 2.png 191 KB View Download

Hmm, still can't reproduce locally... Might be related to caching headers? Can you send the full response headers of said image? Or better yet, host this example online in a way that reproduces the issue?

Oh man I bet the Cache-Control headers for the WEBrick server causes zero caching so it keeps calling to get it, here are the response headers:

Cache-Control:private, max-age=0, proxy-revalidate, no-store, no-cache, must-revalidate
Connection:Keep-Alive
Content-Length:171080
Content-Type:image/png; charset=utf-8
Date:Mon, 11 Jul 2016 08:23:16 GMT
Etag:1137f80-29c48-57834c29
Last-Modified:Mon, 11 Jul 2016 07:35:05 GMT
Server:WEBrick/1.3.1 (Ruby/2.3.0/2015-12-25)

I don't know enough about srcset and cache-control headers and how they affect each other to say for sure.

+japhet@

At least in theory the image resource should have stayed in MemoryCache and fetched from there whenever srcset gets re-evaluated to the viewport changes. Apparently that's not the case here.

Marking as assigned as Yoav took ownership.

Still cannot reproduce locally, even when trying non-cacheable images. 

Christopher, can you please post a (non) working example online so that I can try to reproduce off it?

Thanks!

Going through the code, https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/fetch/ResourceFetcher.cpp?q=ResourceFetcher+store&sq=package:chromium&l=730 may be the cause for this. If ImageLoader triggers a load when it shouldn't of a no-store image, ResourceFetcher will send that request out.

Another potential source - no-store get early removal from memcache for HTTPS resources https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/fetch/Resource.cpp?q=Resource.cpp&sq=package:chromium&dr&l=733

I know this has dragged on and I had honestly forgotten about it. But if you need me to try or do something I would be more than happy to help.

Christopher - do you have a online test case that reproduces this on latest Canary? If so, I'll be happy to take a look, but otherwise, I'm failing to reproduce the error you were seeing.

On Canary (59) 

Environment: WEBrick server with the same response headers seen above.

Still requests every time I resize.

For wide screen it loaded with larger image, refuses to switch to smaller one (which seems correct).
On disable cache checked it goes to small image (due to narrow window), and switches to larger image properly on increasing the width.

Basically: the only issue seems to be constantly issuing requests.

Environment 2: Local React app.

Response Headers:
HTTP/1.1 200 OK
X-Powered-By: Express
Accept-Ranges: bytes
Cache-Control: public, max-age=0
Last-Modified: Thu, 02 Feb 2017 16:44:46 GMT
ETag: W/"2811-159ffb6c830"
Content-Type: image/png
Content-Length: 10257
Date: Mon, 10 Apr 2017 12:34:32 GMT
Connection: keep-alive

Notably the Cache-Control seems less strict...

Result: Everything worked as intended, no extra requests on slow resizing of the width of the browser window.

Next steps:
Since we believe currently that the response headers might be the culprit, how would you like me to put this online? I can spin up a quick AWS EC2 instance or somesuch, install the webrick and a response and give the url, but then you cannot edit the code or the server, unless I get you some ssh credentials (which isn't a horrible idea)... Thoughts?

Thanks! :) If you put something online that I can recreate the issue on, I can take it from there (no need for ssh access)

Alright I created a tiny server running a jekyll boilerplate. It has a srcset image that shifts between a doll and a firetruck.

http://67.205.148.116/

If you browser window is < 350px it should load the doll (hard refresh until it does). Then switch to the network tab and resize it slowly, the doll keeps getting downloaded over and over again as you resize slowly). Once the fire truck shows up it stays and does not redownload (which is interesting I believe when I started the report they both would continually download....).

Please let me know when / if I can take the server down. And if there is anything else I can do.

sooo.... How goes it? Have you had a change to take a look so I can turn off the server?

•͡˘㇁•͡˘

Powering it down since no one is looking at it. Gotta save that $$$ =). Let me know a date you want to look at it and i'll make sure it is live during that day.

Just a little reminder to future me about how to set this up (restore the snapshot, check in bash history. You dont need nginx the whole point is the jekyll WEbrick)

Apologies for the slowness :/ ... I'll ping you once I have time to look into this

np, you have a lot on your plate, I can empathize. Let me know.

Oh my, found this at the bottom of my inbox :(

dilorenzo.christopher@ is this still an issue? Can you turn on the server for me to try to reproduce?

Just call me Chris =).

Thanks for taking a look at this again.

I got a new server going: http://142.93.204.102/

The issue is found by "If you browser window is < 350px it should load the doll (hard refresh until it does). Then switch to the network tab and resize it slowly, the doll keeps getting downloaded over and over again as you resize slowly). Once the fire truck shows up it stays and does not redownload (which is interesting I believe when I started the report they both would continually download....)."

Good luck and happy hunting.

I'm unable to reproduce, but I think our srcset has an extra comma in it, making it the firetruck image the 1x density image

It doesn't show the doll at all? even if you go to less than 350px narrow browser and hard refresh? (I attached a gif of what I see)

Deleted: requestOnResize.gif 6.7 MB

	requestOnResize.gif 6.7 MB View Download

Don't see it at all :/

Looking at the HTML:
<img src="/assets/doll.jpg" sizes="700w" srcset="/assets/doll.jpg 350w, /assets/fire_truck.png, 700w" alt="">

* The comma after "fire_truck.png" seems spurious.
* sizes' value should be a valid CSS length (so maybe you meant "700px")

Interesting.

Too avoid weirdness due to my implementation I changed the example to be the exact same one as in this MDN article: https://developer.mozilla.org/en-US/docs/Learn/HTML/Multimedia_and_embedding/Responsive_images

So the new HTML code is this:
<img srcset="elva-fairy-320w.jpg 320w,
             elva-fairy-480w.jpg 480w,
             elva-fairy-800w.jpg 800w"
     sizes="(max-width: 320px) 280px,
            (max-width: 480px) 440px,
            800px"
     src="elva-fairy-800w.jpg" alt="Elva dressed as a fairy">

I can still see the odd re-downloading behavior in chrome. In firefox it seems to go straight to the 800w image and stays there (regardless of screen width). I also reproduced the behavior on chrome on my wifes computer.

If there is a specific way you want me to write the code I would be happy to do so.

OK, I see the issue and it's clear what's causing it: The image is a no-store image, so it is not reused in the memory-cache.

It seems like the memory cache checks do not implement HTML's "ignore higher layer caching" flag[1] to the letter, and don't let images a pass on "no-store" directives.

yhirano@, kinuko@ - thoughts on bypassing "no-store" for images?

[1] https://html.spec.whatwg.org/#ignore-higher-layer-caching

Yeah we ignore no-cache for images in the availabe images list but do NOT for no-store. Afaik that's been the known behavior, and I'm not 100% sure we should fix this. Maybe yes?

Not sure either. I guess that also depends on what other browsers do.

In any case, this seems to go beyond responsive images (e.g. adding a same-URL image to the page would similarly end up in a double download), so removing myself as owner

Chris - I think the problem is now well-understood, even if the solution is not 100% clear.

Thank you so much for reporting and for spinning up a server to recreate the issue. I think you can spin it down now, if you need to.

As a workaround to avoid the issue - you'd need to make sure your images don't have `Cache-Control: no-store` directives in their HTTP headers.

Excellent, I'll spin down the server. Thanks for hanging out with me and my "hey look at this weird thing"-issue for 2 years =)