Open Bug 1331813 Opened 4 years ago Updated 3 years ago

Cumbersome SVG icon syntax


(WebExtensions :: General, defect, P5)

50 Branch


(Not tracked)



(Reporter: Leif.AMO, Unassigned)


(Whiteboard: [triaged])

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:50.0) Gecko/20100101 Firefox/50.1.0 Waterfox/50.1.0
Build ID: 20161219224911

Steps to reproduce:

1. Read
2. Smile.
3. Delete all PNGs
4. Update browser_action.default_icon = images/icon.svg
5. Read documentation:
6. Frown
7. Search Bugzilla - Find lack of SVG support has been chronic for nearly a decade (at least), with lots of excuses, and weak arguments, but not many solutions.
8. Grumble.

Actual results:

Great, now I can use SVG for browser_action.default_icon, but I still have to use a raster format (like PNG) for the WebExtensions, to get an icon to appear in the AOM (about:addons).

This negates the point of using SVG anywhere at all, as I must still include several resolutions.  It gains me absolutely nothing.  But it's a big step in the right direction!

Expected results:

In manifest.json, any sensible syntax, here are some examples from most sensible to least sensible.

    "icon": "icon.svg",

    "icons": "icon.svg",

    "icons": {
        "*": "icon.svg"

    "icons": {
        "any": "icon.svg"

    "icons": {
        "all": "icon.svg"

    "icons": {
        "16": "icon.svg",
        "32": "icon.svg",
        "48": "icon.svg",
        "64": "icon.svg",
        "96": "icon.svg",
        "128": "icon.svg",
        "256": "icon.svg",
        "512": "icon.svg"

Validation sequence:
1. Usage of "icon" and "icons" mutually exclusive.
2. "icon" must be a string, not an object.
3. "icons", if a string, must be an *.svg file.
4. "icons", if an object, if it has "*", "any" or "all" keywords:
4.a must be mutually exclusive of each other
4.b must be mutually exclusive of any number sizes
4.c file must be an *.svg.
5. "icons" is an object with only numbers for keys, any or all keys may be *.svg file, but all *.svg files must be the same file.
6. Continue with existing validation for "icons".

Note: large icon sizes (128, 256, 512) are for demonstration purposes only, but not unrealistic in what to expect in the near future (next couple years), with massive resolution devices becoming more prevalent, and still growing in size.

Finally, if this is supported, but undocumented, point me at the specific code or summarize syntax, I'll go update the MDN Wiki.
Component: Untriaged → WebExtensions: Untriaged
Product: Firefox → Toolkit
Sorry, but I don't understand the issue. SVG icons are definitely supported here.
I was unable to find any documentation that said the manifest.json key "icons" supported a single SVG file or for any of the individual sizes.  If this is supported but undocumented, it seems silly and redundant to specify the same SVG for multiple sizes.  Maybe just one massive size would work (4096) and let the browser scale it down as needed (effctively a "*" size option), but I could edit the Wiki if I could get the icons to work.

Further experimentation with the

browser_action: { "default_icon": "icon.svg" }

or even

browser_action { "default_icon": { "16": "icon.svg", "32": "icon.svg" } }

Also failed to render the icon anywhere in browser dialogs.

I was able to open the SVG icon as a file with the browser, and the browser rendered the image.  So I do not know what specifically the WebExtensions are expecting to find in that SVG file.  These constraint details need to be documented.

I'd actually expand this bug to SVG files not rendering in any icons.

If I can determine what I did wrong (possibly the case), then I'd like to learn and document the pitfall to help others avoid it.  Is there a webextensions-example on GitHub showing a working SVG file used for all sizes of icons, everywhere?
Flags: needinfo?(kmaglione+bmo)
There are multiple add-ons in our example repository that use SVG for example:

Which demonstrate that they work. Could you attach some files that demonstrate where they don't work please?

If they do work then we could turn this bug into "Specifying a size for an .svg seems odd" bug.
Flags: needinfo?(kmaglione+bmo) → needinfo?(Leif.AMO)
Apologies for delay: system was down, waiting on parts, then rebuild and test, then needed to refresh my memory about this issue.

Using a recent nightly, I am able to get the same SVG icon to show up in the Add-ons Manager (list and detail views), as well as the Browser Action button, and in the Popup content.  Before, I wasn't having luck with that.  So this should revert to "cumbersome manifest.json syntax for SVG icons".

There is a "bug" when using web-ext whereby the Add-ons Manager and Browser Action icons are not updated upon file change.  A page refresh on AOM shows the new icon, but the browser (and error console, if any) must be exited and the browser restarted.  That is a separate issue.

I think what I meant by lack of support, was simply no clear syntax for a truly "scalable" icon.  There's been no specific support of that with manifest/packages/install.rdf syntax.  They all require specifying a size for each and every possible combination of icons on every platform, which is cumbersome.  SVG can cut down file sizes and time maintaining and exporting graphics, which is great, but it'd be nice to also similarly cut down on add-on code.

Also, some images, such as the contextual-identities referenced above, have a width/height/viewBox defined as a 48x48px image, which doesn't scale up even when used in manifest.json (e.g.: "icons": { "64": "icons/identity.svg" }, ).

I'm new to SVG, but to me, the entire concept of SVG is described in the name: scalability.  One should be able to create an image that scales to any arbitrary size.  Perhaps it is my novice misunderstanding?  But, if a height and width is defined, that is just the minimum amount of Cartesian space that is needed to create paths of sufficient quality, and therefore a height/width 48 used in a 64 context ought to scale up (all coords multiplied by 1.3~)?  Or is that incorrect, and they will only ever automatically scale DOWN, not UP?  Scaling down but not up might be a separate issue.

As far as achieving the desired behavior with minimal syntax in the current system, one could simply define an SVG image and corresponding manifest.json icon size of a large number such as 512 or 4096, which ought to be future-proof for a few years.
Flags: needinfo?(Leif.AMO)
Summary: WebExtensions / manifest.json / icons doesn't support SVG → WebExtensions / manifest.json / cumbersome SVG icon syntax
Priority: -- → P5
Summary: WebExtensions / manifest.json / cumbersome SVG icon syntax → Cumbersome SVG icon syntax
Whiteboard: [triaged]
I found the same bug and read that:

What I experienced:

Use SVG with short syntax is possible `browser_action: { "default_icon": "icon.svg" }`. But you need to define both attributes `width` and `height` to complete the `viewBox`.

Also apparently Firefox have a sort of cache for icons. To be sure it use the lastest updated SVG file, you need to... restart it, not only reload the add-on
Product: Toolkit → WebExtensions
Bulk move of bugs per
Component: Untriaged → General
You need to log in before you can comment on or make changes to this bug.