In the output from the test I'm writing in bug 1302570, I have this line: missing file:///.../Nightly.app/Contents/Resources/browser/chrome/devtools/modules/devtools/client/themes/images/filter.svg referenced from file:///.../Nightly.app/Contents/Resources/browser/chrome/devtools/modules/devtools/client/themes/common.css The reference is at http://searchfox.org/mozilla-central/rev/6b94deded39a868f248a492e74e05733d6c4ed48/devtools/client/themes/common.css#547 .devtools-filterinput { background-image: url(images/filter.svg#filterinput); } This is valid when the common.css is accessed from chrome://devtools/skin/common.css, but not when access from the second copy of common.css packaged at http://searchfox.org/mozilla-central/source/devtools/client/themes/moz.build#12, added by bug 1256757. Possible fixes: - package images/filter.svg for resources too. - Make the url absolute in common.css: url("chrome://devtools/skin/images/filter.svg#filterinput"); (like it's done at http://searchfox.org/mozilla-central/source/devtools/client/jsonview/css/search-box.css#13)

(In reply to Florian Quèze [:florian] [:flo] from comment #0) > In the output from the test I'm writing in bug 1302570, I have this line: > Possible fixes: > - package images/filter.svg for resources too. > - Make the url absolute in common.css: > url("chrome://devtools/skin/images/filter.svg#filterinput"); (like it's done > at > http://searchfox.org/mozilla-central/source/devtools/client/jsonview/css/ > search-box.css#13) I like the second option, but I don't understand hwy the packaging for resources (the first option) doesn't work already. The filter.svg is listed in jar.mn file. https://dxr.mozilla.org/mozilla-central/source/devtools/client/jar.mn#206 Honza

(In reply to Jan Honza Odvarko [:Honza] from comment #1) > I like the second option, but I don't understand hwy the packaging for > resources (the first option) doesn't work already. The filter.svg is listed > in jar.mn file. > https://dxr.mozilla.org/mozilla-central/source/devtools/client/jar.mn#206 The jar.mn file is the packaging for chrome://. For an example of the packaging for the resource:// urls, see http://searchfox.org/mozilla-central/source/devtools/client/themes/audio/moz.build#7 http://searchfox.org/mozilla-central/source/devtools/client/themes/moz.build#7

(In reply to Florian Quèze [:florian] [:flo] from comment #2) > (In reply to Jan Honza Odvarko [:Honza] from comment #1) > > > I like the second option, but I don't understand hwy the packaging for > > resources (the first option) doesn't work already. The filter.svg is listed > > in jar.mn file. > > https://dxr.mozilla.org/mozilla-central/source/devtools/client/jar.mn#206 > > The jar.mn file is the packaging for chrome://. I see. So, I don't have a strong opinion, both options work for me. Brian, is there preferred way (in relation to our effort: XUL -> HTML -> WebServer)? Honza

For anything in common.css I'd like to keep paths relative so they even work when loaded over HTTP. So I'd prefer if we packaged it also as a resource.

In bug 1311178, I am reducing duplicate DevTools files, and I ran into this issue from the browser_parsable_css.js test. I chose to go for an absolute chrome:// URL over in that bug, as it seemed like the most expedient thing for right now to eliminate duplicate files. I agree that in the long term, we want relative URLs that can be either resource:// or https://. There are various other chrome:// URLs in common.css as it stands, so we'll need to tackle conversion to resource:// URLs more generally. Speaking of that, there's now bug 1311541 to track shipping all DevTools CSS over resource:// in product, so that seems like the right bug for the general issue.

Fixed by bug 1311178.