Thank you for the report! Could you collect and provide net log according to these instructions: https://sites.google.com/a/chromium.org/dev/for-testers/providing-network-details

here you go

Deleted: net-internals-log.json 111 KB

net-internals-log.json 111 KB View Download

Thanks for the log! There indeed are no requests to f193e7971172bcbd74ae918b7343dd63.jpg, which means that they are corrupted somewhere above the network stack.

Would it be helpful if I set-up this page online and post the link so it can be reproduced?

Reproduction URL will help a lot.

Cannot repro neither with 48.0.2564.116 nor with 51.0.2672.0 (see attached html, you'll need original.png nearby). Does this repro for you?

Deleted: with_image.html 354 bytes

with_image.html 354 bytes View Download

This repro for me all the time, that CSS is not sufficient to trigger the issue -- and I confirmed that before as I was hoping as well that it was sufficient. Will publish a static page tomorrow for demonstrating the bug.

I just setup a server where the issue can be reproduced: http://52.86.248.16:8080
Will keep it online while this issue is open

Interestingly a static page was not suffisant either, although it may have been possible. Making a static build of this component did not reproduce this issue. But it happens either when serving it through webpack-dev-server or integrating the component on our production site. Which is why I had to setup a server -- which serves this component through webpack-dev-server.

After seeing the exact same issue in Firefox (also adding chrome-devtools://devtools/), I am suspecting that it is originating in react-transform-hmr, webpack-dev-middleware or one of their dependencies and have reported the issue at: https://github.com/gaearon/react-transform-hmr/issues/67. Furthermore, I have excluded that this was the issue on our production server as this was caused by a CSS rule declaration order overwrite.

Stylesheet is loaded using blob scheme (blob:http%3A//52.86.248.16%3A8080/1c8e0829-328a-4ce4-ab0d-4fe0d410ae73), and has relative url inside:

background: 
    -webkit-linear-gradient(top, rgba(255, 255, 255, 0) 0, rgba(255, 255, 255, 1) 250px), 
    url(/assets/4fccb2f5b96a8f04ceeb7b10a83f5b43.jpg) no-repeat -40px -170px,
    white;

I think blob scheme may prevent relative path resolution from working properly.
@rune, @jsbell: do you know how this is supposed to work?

I don't know

I don't know either; I have no expectations that a relative path composed with a Blob URL would work, as it is not defined anywhere. 

Does this attached sample accurately represent what's being seen?

The "chrome-devtools://devtools/" stuff being added in devtools is almost certainly just devtools leaving the URL fragment relative. ISTM devtools should be reporting this as an error (maybe that's the intent of the bug?)

Deleted: relblob.html 492 bytes

relblob.html 492 bytes View Download

re #c13: I think that attached sample is correct.

I will work on a fix for prepending "chrome-devtools://devtools/". That's definitely a devtools bug (we probably do not understand blob url).

That sample makes more sense if you have google.png (saved from google's home page) in the same dir and are serving it as the root. :)

Behavior in FF: no background shown. FF's devtools shows an image on hover (as if it's resolving relative to the page's URL) but right-click copies just the relative URL.

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

commit f82e78397ae82e65234d5449297aa3a6661055c4
Author: dgozman <dgozman@chromium.org>
Date: Fri Mar 18 21:17:14 2016

[DevTools] Do not linkify relative urls.

They happen to point to some DevTools frontend file, which is misleading at best.

BUG= 591123 

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

Cr-Commit-Position: refs/heads/master@{#382087}

[modify] https://crrev.com/f82e78397ae82e65234d5449297aa3a6661055c4/third_party/WebKit/Source/devtools/front_end/common/ParsedURL.js
[modify] https://crrev.com/f82e78397ae82e65234d5449297aa3a6661055c4/third_party/WebKit/Source/devtools/front_end/components/Linkifier.js
[modify] https://crrev.com/f82e78397ae82e65234d5449297aa3a6661055c4/third_party/WebKit/Source/devtools/front_end/platform/utilities.js

I think we can close this now. With patch from #c17 we do not show wrong url in DevTools, and since relative url for blob origin does not really work, developers can figure that out now.

Agreed.

Someone sufficiently motivated might want to file a bug against Safari.