Closed
Bug 1416400
Opened 7 years ago
Closed 7 years ago
WebExtension add-on's browser action icon doesn't get color filled
Categories
(WebExtensions :: Frontend, defect, P2)
Tracking
(Not tracked)
RESOLVED
DUPLICATE
of bug 1421329
People
(Reporter: cr0ydon, Unassigned)
Details
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:56.0) Gecko/20100101 Firefox/56.0
Build ID: 20171024165158
Steps to reproduce:
I have a WebExtension add-on that uses svg files for the icons. Since I want that the icons fill as "native" as possible I want that the color adapts.
Actual results:
This works in the sidebar header and on the customize page as Firefox seems to apply the CSS fill attribute here with the currentColor.
It does not work for browser_action icons when placed next to the navbar.
Expected results:
Firefox should apply the CSS fill attribute with the currentColor (current text color) to browser_action icons when placed next to the navbar.
Updated•7 years ago
|
Component: Untriaged → WebExtensions: General
Product: Firefox → Toolkit
Updated•7 years ago
|
Flags: needinfo?(amckay)
Updated•7 years ago
|
Status: UNCONFIRMED → RESOLVED
Closed: 7 years ago
Flags: needinfo?(amckay)
Resolution: --- → DUPLICATE
Comment 2•7 years ago
|
||
Actually, this might not be a dupe, currentColor isn't the same as context-fill. Do you have a simple example SVG icon that would demonstrate this?
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: DUPLICATE → ---
Comment 3•7 years ago
|
||
I wonder if changing the behaviour of fill="currentColor" would be better than exposing fill="context-fill". currentColor is a standard keyword, while context-fill is not.
Flags: needinfo?(jwatt)
Comment 4•7 years ago
|
||
(In reply to Croydon from comment #0)
> I have a WebExtension add-on that uses svg files for the icons. Since I want
> that the icons fill as "native" as possible I want that the color adapts.
>
> This works in the sidebar header and on the customize page as Firefox seems
> to apply the CSS fill attribute here with the currentColor.
To help here I need to understand the structure of the "sidebar header" and "customize page", and how the icons are added to them. Can someone point me to the source of these two pages and describe how the icons are embedded? Are they referenced as a separate image file somehow? Or is the markup of the SVG inserted into these pages?
Flags: needinfo?(jwatt)
Comment 5•7 years ago
|
||
I imagine that the markup of the SVGs must be inserted into these pages if 'currentColor' is working, but then I didn't think WebExtensions were allowed to do that...
Comment 6•7 years ago
|
||
SVGs are still used as images, so they can't access the color. What that would be nice to do is somehow expose the color Firefox uses to the extensions, basically something like context-fill.
I see two solutions that could be done:
- Set the `color` property in the SVG image context when it is loaded to the color that Firefox is using
- Set a CSS variable in that SVG image context
I would suspect the second solution is better, but it would really be nice to have an alternative to context-fill that extensions can use. It's blocking things like the icons theming API that it would be nice to push forward.
Flags: needinfo?(jwatt)
Updated•7 years ago
|
Priority: -- → P2
Updated•7 years ago
|
Component: WebExtensions: General → WebExtensions: Frontend
Comment 7•7 years ago
|
||
(In reply to Tim Nguyen :ntim from comment #6)
> SVGs are still used as images, so they can't access the color. What that
> would be nice to do is somehow expose the color Firefox uses to the
> extensions, basically something like context-fill.
>
> I see two solutions that could be done:
> - Set the `color` property in the SVG image context when it is loaded to the
> color that Firefox is using
That's limited to a single color, and lots of our icons want two colors.
> - Set a CSS variable in that SVG image context
See bug 1421329.
> I would suspect the second solution is better, but it would really be nice
> to have an alternative to context-fill that extensions can use. It's
> blocking things like the icons theming API that it would be nice to push
> forward.
Sounds like this is essentially a dupe of bug 1421329 then. Incidentally, where can I find info on the theming API?
Flags: needinfo?(jwatt)
Updated•7 years ago
|
Status: REOPENED → RESOLVED
Closed: 7 years ago → 7 years ago
Resolution: --- → DUPLICATE
Updated•6 years ago
|
Product: Toolkit → WebExtensions
You need to log in
before you can comment on or make changes to this bug.
Description
•