Bug 42953 – SVG gradients do not update when scripted via xlink

• Component: SVG
• Status: RESOLVED FIXED

[mg]

Created attachment 62536 [details]
Simple test case showing bug.

The scenario is:
1) A linear gradient is defined in a def.
2) That gradient is referenced by another def (via url).
4) That second def is used for the fill via url (e.g. fill="url(#xlinkedgradient)" ).
4) The original gradient stops are then modified via Javascript.

The result is the fill in the SVG element does not update on the screen unless the update is somehow "forced" (e.g. by hiding and then showing the element). Note that this is unrelated to other reports involving "use" or external SVG. There is no "use" or external elements involved. This is all in a single SVG file. 

This works in some Webkit browsers but not others:

1) Does NOT work with Safari 5.0 (7533.16) on MS Windows XP.
2) Does NOT work with Chromium 6.0.453.0 (51332) Built on Ubuntu 9.04, running on Ubuntu 10.04.
3) Does NOT work with Midori 0.2.2  WebKitGTK+ 1.1.21.
4) Does NOT work with Epiphany Web Browser 2.30.2. (Viewing the "about" window or reducing the window to the task bar and then restoring it rather interestingly however gives Webkit enough of a kick to force a single screen update each time). 

5) DOES work OK on with Chrome Chrome 5.0.375.99 on MS Windows XP.


Where the situation involving gradients arises is when manipulating a drawing using Inkscape (and possibly other drawing editors as well). The drawing editor will in many situations replace the direct url reference to the gradient fill with an indirect one using xlink (it does this when adding more properties). Applications involve creating drawings using Inkscape and then manipulating them using Javascript. This is typical in applications where you want to use SVG as a replacement for something traditionally done with Flash, Java, or ActiveX. Doing large drawings by hand is impractical, so a drawing editor (such as Inkscape) must be used. I have a software project where this bug was showing up in the standard demo. I have patched the demo by hand, but the problem still exists for people attempting to create their own applications.

This feature works fine (and has always worked fine) in all versions of Firefox or Opera that I've tested. The problem seems to exist in Webkit only. At present I can tell affected users to use one of those browsers until this bug is sorted out. 

Note that the problem appears present in *most* Webkit browsers, but at in least one version it does not (see above). The problem *seems* to have come and gone and then returned from time to time with different versions, although I can't give any details on that since I only recently tracked down what was actually going on. 

The attached file illustrates the problem in a simplified form (I created the SVG by hand for this example). It shows three polygons. The left two polygons show a fill property which gives the appearance of a level of liquid alternately filling and lowering in column gauges. The right polygon references the gradient via xlink, and does not update (although it can be forced to update if you can force the screen to redraw).

[Dirk Schulze]

Second gradient doesn't get invalidated on the change of the first, referenced, gradient changes.

[Radek Pietruszewski]

I guess that's the same bug as bug 42944 - with the difference that I was talking about SVG backgrounds, not standalone SVGs.

[Nikolas Zimmermann]

Wonderful testcase and investigation, it's highly appreciated!
We're going to look into this soon.

[Dirk Schulze]

(In reply to comment #2)
> I guess that's the same bug as bug 42944 - with the difference that I was talking about SVG backgrounds, not standalone SVGs.

No, they are unrelated even if they seem to share the same problem.

[Nikolas Zimmermann]

Created attachment 63033 [details]
Even more reduced testcase

Bug is valid, can fix this now with the new SVGResourcesCache approach.

[Nikolas Zimmermann]

Created attachment 63059 [details]
Patch

Included slightly modified variant of the testcase within the LayoutTests. Bug is finally fixed :-)

[Nikolas Zimmermann]

Created attachment 63062 [details]
Updated patch

Oops, left in some debugging code.

[Dirk Schulze]

Comment on attachment 63062 [details]
Updated patch

great patch. We should start to document resources somehow. :-) r=me

[Nikolas Zimmermann]

Landed in r64440. Check out your testcase with a nightly!