Open
Bug 1411628
Opened 7 years ago
Updated 2 years ago
SVG icon url fragment incorrectly escaped (by web-ext?) in the Add-ons Manager
Categories
(Toolkit :: Add-ons Manager, defect, P3)
Tracking
()
UNCONFIRMED
Tracking | Status | |
---|---|---|
firefox57 | --- | wontfix |
People
(Reporter: Leif.AMO, Unassigned)
Details
Attachments
(1 file)
2.16 KB,
application/x-xpinstall
|
Details |
User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:52.0) Gecko/20100101 Firefox/52.0.2 Waterfox/52.0.2 Build ID: 20170412235751 Steps to reproduce: Note: This error seems to occur only when using the Node.JS package "web-ext" to test an add-on. Manual archival to a .zip file, rename to .xpi, signature verification disabled, and local install, leaves the URL fragment alone. Created a WebExtension with an SVG file using a CSS sprite technique, tested with "web-ext" command line utility that starts Firefox with a temporary profile and installs a "live" copy of the add-on. The SVG Sprite technique is used to define image structure once with <symbol> tags, and styled with <g> tags with ids and set to display none by default. The desired image is then selected by specifying SVG file name a document fragment (e.g. icons.svg#sprite-0, icons.svg#sprite-1, etc), which causes the CSS to make only the target display. This technique works for the browser_action button icon, as well as the context menu icons. Actual results: When running a text with "web-ext" during development, the Add-ons Manager (about:addons) List View and Detailed View (possibly others?) do not display any icon. Further DOM Inspection (CTRL-SHIFT-C) show that the fragment separator character (#) is being escaped (%23) so that the browser is looking for a nonexistent file name (e.g. icons.svg%23sprite-0 or a file with the name icons.svg#sprite-0), rather than correctly interpreting # as a special document fragment character. For some reason it appears that "web-ext" is choosing to mangle URL fragments. Expected results: Icons should be displayed. # should remain unescaped. The fragment inside the document should be accessed. Behavior should be consistent with other browser internal code such as browser action button and context menu icons. I've included a little SVG Icon Sprite Demo WebExtension add-on. It has 3 distinct symbols, each with 2 styles, which are displayed in 4 sizes each as both the inline options page and the browser action popup, and in a 5th smaller size on the browser action context menu. Manually editing the image URL using DOM Inspector to change %23 to # results in image immediately being displayed correctly. As does manual packaging and installation of add-on. The only faulty variable is "web-ext".
Updated•7 years ago
|
Component: Untriaged → Add-ons Manager
Product: Firefox → Toolkit
Not entirely sure if it's web-ext causing this, or some interaction with Mozilla Add-ons Manager when run with whatever settings web-ext is using to actually call the .exe. Not sure precisely what web-ext does when starting Firefox, but that would be a way to more definitively isolate cause to either web-ext or Firefox. I create a new profile to use for each new version of Firefox installed. Am using a basic command line: web-ext run --firefox "C:\Program Files\Mozilla\Firefox\58.0a1\firefox.exe" -p "C:\Users\~USER~\AppData\Local\Mozilla\Firefox\Profiles\typa0wad.FF-58.0a1-Win64" --bc
Updated•7 years ago
|
status-firefox57:
--- → wontfix
Comment 2•7 years ago
|
||
Hi Leif-AMO, is this issue reproducible also when installing the extension as a temporarily installed extension from "about:debugging#addons"?
Flags: needinfo?(Leif.AMO)
Priority: -- → P3
Checked with Fx 57.0b13 and 58.0a1 2017-11-01-22-01-20 using an .xpi. Image displays correctly there. The %23 remains as a # character, and the SVG is processed correctly. The about:debugging#addons path is of the form: jar:file:///path/to/addon.xpi!/icons.svg#logo Whereas when using web-ext, the path is of the form: file:///path/to/addon.dir/icons.svg%23logo
Flags: needinfo?(Leif.AMO)
Comment hidden (spam) |
Comment hidden (spam) |
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•