Created attachment 109404 [details] show problem with css The following happens to me often in Mac 10.6.8 and Windows 7: When I modify the css data in the Developer tools> Elements panel> Styles subpanel, if I click on the link to my css, see point 1 in the image, the result is the point 2 in the Resources panel and 3 in the console of the image. If I refresh the browser it works correctly again, so I guess it's no problem of my css.
Created attachment 109405 [details] add url() to background:#fff
Comment on attachment 109405 [details] add url() to background:#fff Finally, I have found when this problem happens. If I have a background: # 930 and I add url (image / photo.jpg) the problem appears
Does the same happens if you add an empty url() in you CSS file, not in Web Inspector?
(In reply to comment #3) > Does the same happens if you add an empty url() in you CSS file, not in Web Inspector? I made an experiment and found that <div style="background: url()"> in html file forces the browser to load html file second time. The warning "Resource interpreted as Other but transferred with MIME type undefined." appears in console too. You are right. This is not a Web Inspector specific problem.
Could you please attach your test case? This sounds like a missed case in bug 30303 and related bugs.
(In reply to comment #5) > Could you please attach your test case? > > This sounds like a missed case in bug 30303 and related bugs. http://www.w3.org/TR/CSS2/syndata.html#uri Relative URIs (as defined in [RFC3986]) are resolved to full URIs using a base URI. RFC 3986, section 5, defines the normative algorithm for this process. For CSS style sheets, the base URI is that of the style sheet, not that of the source document. So according to spec adding url() to css triggers another load if this stylesheet as an image, this is not a bug. From this moment on CachedResource stored in MemoryCache for this url has Image type, and it is not possible to correctly show it in Web Inspector. See also http://code.google.com/p/chromium/issues/detail?id=84605 for the same problem.
Sorry for a typo: So according to spec adding url() to css triggers another load OF this stylesheet as an image, this is not a bug.
Created attachment 109418 [details] Test case Alexey, I've read this bug you mentioned, it's the same issue but for CSS. Since I can't think of any good reason to use stylesheet as an image, I think this could be fixed the same way. Currently Firefox has the same behavior as WebKit. See test attached.
(In reply to comment #8) > Created an attachment (id=109418) [details] > Test case > > Alexey, I've read this bug you mentioned, it's the same issue but for CSS. > Since I can't think of any good reason to use stylesheet as an image, I think this could be fixed the same way. > > Currently Firefox has the same behavior as WebKit. See test attached. I do not know if this is a webkit bug but when you click on the link to the css in the Developer tools> Elements panel> Styles subpanel, you should go to the css, because the path is to the css.
*** Bug 78377 has been marked as a duplicate of this bug. ***
See https://drafts.csswg.org/css-values-3/#url-empty, with tests at https://github.com/web-platform-tests/wpt/blob/master/css/css-values/urls/empty.html https://github.com/w3c/csswg-drafts/commit/e0518924c87638861e6b89cc303667b9421cf152 changed the behaviour per spec to "resolve to an invalid resource (similar to what the url about:invalid does)". Per https://github.com/w3c/csswg-drafts/issues/6447, CSS Values doesn't actually define _what_ the computed value is, though Gecko has implemented this with about:invalid. https://bugs.chromium.org/p/chromium/issues/detail?id=910954 is the Blink bug for this.
<rdar://problem/80536093>
Safari is only browsers passing this test case: https://wpt.fyi/results/css/css-values/urls/empty.html?label=master&label=experimental&aligned&view=subtest&q=css-value gsnedders@apple.com - Do we need this? or we can mark this as "RESOLVED CONFIGURATION CHANGED"? Thanks!
While we pass both that and https://wpt.fyi/results/css/css-images/empty-background-image.html?label=master&label=experimental&aligned&view=subtest (which purportedly tests the actual behaviour of empty URLs, albeit relying on Navigation Timing as a source of truth), I'm still not totally sure we actually treat them as invalid and avoid the request entirely—I can't see anywhere in the code where we do. Simon?