images/filter.svg is missing when accessed from the JSON Viewer's common.css file

RESOLVED FIXED

Status

defect
P1
normal
RESOLVED FIXED
3 years ago
11 months ago

People

(Reporter: florian, Assigned: jryans)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Reporter

Description

3 years ago
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

3 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
(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

3 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)
(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)
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

3 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: nobody → jryans
Status: NEW → ASSIGNED
Depends on: 1311178
Priority: -- → P1
Assignee

Comment 6

3 years ago
Fixed by bug 1311178.
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED

Updated

11 months ago
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.