Closed
Bug 1302708
Opened 8 years ago
Closed 8 years ago
images/filter.svg is missing when accessed from the JSON Viewer's common.css file
Categories
(DevTools :: JSON Viewer, defect, P1)
DevTools
JSON Viewer
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: florian, Assigned: jryans)
References
Details
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)
Reporter | ||
Updated•8 years ago
|
Summary: images/filter.svg is missing when access from the JSON Viewer's common.css file → images/filter.svg is missing when accessed from the JSON Viewer's common.css file
Comment 1•8 years ago
|
||
(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
Flags: needinfo?(florian)
Reporter | ||
Comment 2•8 years ago
|
||
(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
Flags: needinfo?(florian)
Comment 3•8 years ago
|
||
(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
Flags: needinfo?(bgrinstead)
Comment 4•8 years ago
|
||
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.
Flags: needinfo?(bgrinstead)
Assignee | ||
Comment 5•8 years ago
|
||
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.
Assignee | ||
Comment 6•8 years ago
|
||
Fixed by bug 1311178.
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Updated•6 years ago
|
Product: Firefox → DevTools
You need to log in
before you can comment on or make changes to this bug.
Description
•