In recent mozilla-central nightlies, the Adobe SVG "wonder" demo has been missing the orange-ish block on the front. In fact, I think we're not displaying this element at all: http://www.adobe.com/svg/demos/animClippath/images/wndw.jpg Regression range: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a3pre) Gecko/20100301 Minefield/3.7a3pre http://hg.mozilla.org/mozilla-central/rev/e7970f6c7cdd Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a3pre) Gecko/20100302 Minefield/3.7a3pre http://hg.mozilla.org/mozilla-central/rev/ba77049941c3 http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e7970f6c7cdd&tochange=ba77049941c3 There are a few SMIL changes in that range, but Bug 547062 looks more suspicious to me, given the use of clipPath in the broken document. Here's a snippet of the broken document (with whitespace cleaned up, for readability): > <g id="maskedPict2" style="&st2;"> > <g> > <clipPath id="aiclp2" style="&st0;"> > <rect x="98" y="0" width="5" height="300"/> > <animateTransform attributeName="transform" type="translate" values="0 0;-20 0;-90 0;0 0" > calcMode="spline" keyTimes="1;7;9" keySplines="0 .5 .25 .5;.2 0 .75 0" > additive="sum" dur="10s" repeatDur="indefinite"/> > <animateTransform attributeName="transform" type="scale" values="0.25 1;3 1;0.5 1;1 1" > additive="sum" dur="9s" repeatDur="indefinite"/> > </clipPath> > <g style="&st4;"> > <image x="0" y="-5" width="400" height="310" > xlink:href="http://www.adobe.com/svg/demos/animClippath/images/wndw.jpg" /> > </g> > </g> > </g>

(In reply to comment #0) > There are a few SMIL changes in that range, but Bug 547062 looks more > suspicious to me, given the use of clipPath in the broken document. Confirmed -- if I revert Bug 547062's patch (with "hg export ba77049941c3 | patch -R -p1"), I see chunks of orange from wndw.jpg again. (It still is slightly broken, though -- the "wndw.jpg" slices don't seem to repaint automatically, until something else moves across them. This makes them look "frozen" for periods of time. That may be a regression from a more recent change.)

http://www.w3.org/TR/SVG/masking.html#EstablishingANewClippingPath A 'clipPath' element can contain 'path' elements, 'text' elements, basic shapes (such as 'circle') or a 'use' element. !ENTITY % SVG.clipPath.content is not consistent with this and allows animation and description so I guess those should be allowed too although the content list should be made consistent in the specification.

This is one way to do it.

This seems much better though.

Comment on attachment 433311 [details] [diff] [review] better patch Looks good to me. Could you add a reftest for good measure? I verified that this patch fixes the bug, though I still get the (new) repaint issues described in comment 1... I guess that's a separate issue that regressed while this was broken. I'll file a separate bug on that.

(filed Bug 553416 on the new repaint issue)

Comment on attachment 433311 [details] [diff] [review] better patch asking for SR since this touches a number of modules even though it's fairly straightforward.

I'll add a reftest before landing too. A clipPath with an empty animateTransform should do.

checked in http://hg.mozilla.org/mozilla-central/rev/e2c79d3c12f7