If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

SVG icon is not rendered correctly in extension temporary installation/options views

VERIFIED INVALID

Status

()

Core
SVG
P3
normal
VERIFIED INVALID
23 days ago
10 days ago

People

(Reporter: User Dderss, Unassigned)

Tracking

55 Branch
Points:
---

Firefox Tracking Flags

(firefox57 fix-optional)

Details

Attachments

(6 attachments)

(Reporter)

Description

23 days ago
Created attachment 8903942 [details]
colour-visited-urls.svg

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:55.0) Gecko/20100101 Firefox/55.0
Build ID: 20170824053622

Steps to reproduce:

Created an SVG icon with the use of the latest Inkscape vector graphics editor (saved, as advised in the documentation, in simple SVG format) for my web extension.


Actual results:

While the icon is displayed properly in general extensions list, it gets cut around the borders in the temporary installed extension view, and, much worse, gets totally skewed rendering in extensions' options view.


Expected results:

The icon should be displayer correctly in all three modes/views, not just in one.
(Reporter)

Updated

23 days ago
Component: Untriaged → SVG
Product: Firefox → Core
(Reporter)

Comment 1

23 days ago
Created attachment 8903943 [details]
Proper SVG, saved as simple, via lated Inkscape.png
(Reporter)

Comment 2

23 days ago
Created attachment 8903944 [details]
Totally correct SVG rendering in general list of installed extensions.png
(Reporter)

Comment 3

23 days ago
Created attachment 8903945 [details]
Right side of SVG is cut in termporary extension installation view.png
(Reporter)

Comment 4

23 days ago
Created attachment 8903946 [details]
Lower part of SVG is shifted to the left in extension options view.png

Updated

17 days ago
Priority: -- → P3
Thanks for the bug report. Could you post the extension itself (or even a dummy version of the extension with just the image), for testing purposes?  (Or alternately, steps to create an extension with the image, so that folks looking at this bug can reproduce the rendering shown in your screenshots, for further investigation.)
status-firefox57: --- → fix-optional
Flags: needinfo?(zxspectrum3579)
(Reporter)

Comment 6

11 days ago
Created attachment 8908474 [details]
Extension.rar

The extension is not really ready, but here it is.
Flags: needinfo?(zxspectrum3579)
Thanks!

On my (linux) system I'm not seeing the "Lower part of SVG is shifted to the left" issue, but here are a few observations:

 (1) I'm not surprised that you're seeing it shifted left, since that <text> has |x="-0.44859466"|, which (for a high enough resolution) gets rounded up to a full pixel of being offset to the left.  So I think that some possible-1px-left-shifting there is expected.

 (2) I do see some right-edge text clipping at various zoom levels, like in your attachment 8903945 [details]. I can reproduce the clipping by just loading the SVG (attachment 8903942 [details]) directly -- i.e. in its own tab -- and zooming in and out with Ctrl +.  This kind of emulates what's happening in the addon UI, where the image is shown at various sizes.  On my system, the "D" in "VISITED" is clipped at the default zoomlevel, and if I zoom in 2x or 5x. I believe that's to be expected too, though, because:
  (a) You're not providing your own font, so you'll just get whatever font the system happens to pick. So you don't have any particularly good guarantees about how big the text will be.

  (b) Setting that aside: fonts are tricky, so a given font rendered at 2x size won't necessarily produce *exactly* 2x the width. It might be slightly wider, as it seems to be in this case.


So I think this bug is INVALID because you're asking SVG text to provide you more guarantees than it actually can provide.

I'm not an icon designer, so I don't claim to know best practices here -- but I'd bet if you want this to work reliably, you should consider doing the following:

EITHER:
 (1) don't use text -- instead, draw the text using shapes, which will scale nicely and won't invoke a font engine.
OR:
 (2) provide your own font (as a base64-encoded data URI, for example) inside of the SVG icon, so that you actually have good cross-platform guarantees (and you're not beholden to the renderer's font engine & its choice of font).  And include 1px or so of buffer around the edge, so that any rounding issues don't end up making your rightmost pixel of text get clipped.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 10 days ago
Resolution: --- → INVALID
(Reporter)

Comment 8

10 days ago
Thanks, Daniel.

I have transmutated text object into vector ("Object to path" in Inkscape), and this has helped.

I am not a professional in SVG at all, and Inkscape does not tell you if it only saves text with a reference to some abstract font, I though it should include the vector for letters used, but it does not, and there is no warning.

Could you please update Mozilla's web extensions' tutorial for it to include a warning for newbies such as myself? Something like: "if your icon contains text, make sure you convert it to a vector object as otherwise consistent rendering is not guaranted".

Thank you in advance.
(In reply to User Dderss from comment #8)
> I have transmutated text object into vector ("Object to path" in Inkscape),
> and this has helped.

Perfect, that sounds like exactly the right way to fix this.  I'm glad Inkscape makes this option available.

> Could you please update Mozilla's web extensions' tutorial for it to include
> a warning for newbies such as myself? Something like: "if your icon contains
> text, make sure you convert it to a vector object as otherwise consistent
> rendering is not guaranted".

I'm guessing you're talking about this doc:
 https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Your_first_WebExtension

I added a caveat after the mention of SVG for icons there:
  # Alternatively, you could supply an SVG file here, and it will be scaled correctly.
  # (Though: if you're using SVG and your icon includes text, you may want to use your
  # SVG editor's "convert to path" tool to flatten the text, so that it scales with a
  # consistent size/position.)

(The first line is the existing documentation, the other lines are what I added.)

I used the term "Convert to path" since that's what Inkscape's English documentation seems to call this feature. (See  https://inkscape.org/en/doc/tutorials/advanced/tutorial-advanced.en.html , "Converting to path" section).  That should be enough of a hint to steer people in the right direction.
(Reporter)

Comment 10

10 days ago
Thanks, Daniel.

Did you look at YouTube's latest client JS engine update? It seems that the latest trend is to get rid of as much raster images as possible, and replace them with SVG (be it inline vector code or links to SVG files). 

Could you please consider with your colleagues to make the SVG instructions as the primary recommended practice in the tutorial? This also would remove the necessity to define sizes like "48", "96", and so on in the Manifest file.

Additionally, Firefox/Thunderbird/et cetera as whole should also exclude any and all raster graphics everywhere, making it ever sharp and infinitely scalable. Even cheap Android phones by now have decent 2D vector acceleration capabilities, so such transition could be done on common multi-platform resource storage level.
(In reply to User Dderss from comment #10)
> Could you please consider with your colleagues to make the SVG instructions
> as the primary recommended practice in the tutorial? This also would remove
> the necessity to define sizes like "48", "96", and so on in the Manifest
> file.

I'll pass that along if I run into folks on our WebExtensions team. (I don't immediately know who the right person would be to direct that feedback to.)

I imagine the situation might be slightly complex, e.g. perhaps they're trying to make that guide approachable to legacy addon authors who are rewriting their addons as WebExtensions, and who already have PNG assets.  And maybe we don't want to scare them away by pushing SVG on them. *shrug*, I dunno.

> Additionally, Firefox/Thunderbird/et cetera as whole should also exclude any
> and all raster graphics everywhere, making it ever sharp and infinitely
> scalable.

On desktop Firefox at least, we're already replacing the icons in Firefox UI with SVG versions, as part of the "photon" retheming, which ships in Firefox 57 -- see e.g. bug 1347543 (and bug 1355455 which I think switches them on).  You can see the new UI in current Nightly versions, if you like.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.