Closed Bug 353575 Opened 18 years ago Closed 5 years ago

gradients, clipPaths and masks inside svg:symbol aren't rendered

Categories

(Core :: SVG, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla77
Tracking Status
firefox77 --- fixed

People

(Reporter: takenspc, Assigned: emilio)

References

(Blocks 1 open bug)

Details

Attachments

(2 files, 1 obsolete file)

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20060918 Minefield/3.0a1 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20060918 Minefield/3.0a1 gradients inside svg:symbol aren't rendered. gradients outside svg:symbol are rendered. Reproducible: Always Steps to Reproduce: 1.Open a svg file which has gradient(s) inside svg:symbol aren't rendered. 2. 3. Actual Results: gradient(s) are not rendered. Expected Results: gradient(s) are rendered.
Attached image testcase
4 rects shuld have same gradient.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060920 Minefield/3.0a1 Confirmed.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Why would you put the gradient _inside_ the symbol? The elements in the symbol are probably cloned into a shadow tree, in which case you're increasing memory use (and there are going to be multiple shadow elements with the same ID).
(In reply to comment #3) > Why would you put the gradient _inside_ the symbol? Adobe Illustrator 12.0.1, SVG Export Plug-In exports svg files which include the gradient inside the symbol. For example, http://spreadfirefox.jp/foxkeh/downloads/parts/tail01.svg another examples at http://spreadfirefox.jp/foxkeh/downloads/parts/ # A mascot in those pages is Foxkeh, a mascot of Firefox brought by Mozilla Japan.
#3 jwatt asks "Why would you put the gradient _inside_ the symbol?" one reason is authoring tool user interface. beyond hand coding... ie unless a number of icons are saved as a set at one time, each will have the gradients, then when the icons are agglomerated, there is much duplication: http://www.openicon.org/icon-ark/freedesktop/gnome/devices.svgz
Assignee: general → nobody
QA Contact: ian → general
For the SVG-edit project, I'm working on arbitrary SVG importing. The idea is to insert a <symbol> element with the data, so multiple copies can be made using <use>. This bug means that import files with gradients will thus appear filled in black when using Firefox. As a workaround I was going to put the imported <svg> in a <defs>, then have the <use> elements refer to that, but unfortunately Adobe Illustrator incorrectly displays an image like this (it does fine with <symbol>). A bug on their part, certainly, but it forces me to decide whether to support Firefox or Illustrator. Considering how <symbol> is very very similar to <svg> elements (in which this bug does not occur), I find it hard to imagine that this bug would be hard to fix.
Just FYI: The Foxkeh assets, including the broken tail SVG files in comment 4, have been moved to http://www.foxkeh.com/downloads/parts/
OS: Linux → All
Hardware: x86 → All
Attachment #574211 - Attachment is obsolete: true
Summary: gradients inside svg:symbol aren't rendered → gradients, clipPaths and masks inside svg:symbol aren't rendered
Blocks: svg-enhance

I think this should be easy to fix, actually.

Assignee: brian → emilio

Other UAs allow this, and it seems in the general consensus of
https://github.com/w3c/webcomponents/issues/179.

This matches WebKit's behavior. Blink, for some reason shows red on the
test-case, probably because they're not doing quite this, but they
manage to render masks inside the display: none symbol element or such.

Pushed by ealvarez@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/8efff752175e Allow IDTracker to look up elements in <svg:use> shadow trees. r=smaug
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla77
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: