Chrome Version       : 63.0.3239.84 (Official Build) (64-bit)
Other browsers tested:
    Safari: OK 10.1 (12603.1.30.0.34)
    Firefox: OK 57.0

Summary:
It's common practice to force image invalidation through the use of url fragments. All other modern browsers support this. I believe Chromium used to do this as well, but seems to no longer work. This is particularly worrisome when image is sent with no-cache headers. If an image url is not cacheable, then any <img> tag added to the page dynamically with a src known to be no-cache should require a new http request.

What steps will reproduce the problem?
(1) Host an image file on a web server with no-cache headers (i.e Cache-Control: max-age=0, private, must-revalidate)
(2) Add an <img> element with a src pointing to the hosted image
(3) Replace the image file on the server with a different image (of the same name)
(4) Dynamically add a new <img> tag to the page with the same src url as the first image
(5) Dynamically add a new <img> tag to the page with the same src url, PLUS a random url fragment appended to the url (i.e. http://example.com/foo.jpg#abc123)
(6) Modify the original <img> src, appending a new random fragment to the url

What is the expected result?
The browser should display the "updated" image from the server in each step, 4-6


What happens instead?
No change to the images. No http requests made. The only way to get the "updated" image is to use an entirely new src url (for example, by appending an HTTP GET param)