STEPS TO REPRODUCE: 1. Load Adobe "wonder" demo. Watch the "foreground" image on the left (the image with the orange rectangle in it) EXPECTED RESULTS: The edges of the slices that show the foreground image should be constantly moving. ACTUAL RESULTS: The edges of the slices periodically stop moving, usually until another moving chunk of the image crosses over them. Looks like a repaint issue. Regression range: * WORKS: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a3pre) Gecko/20100301 Minefield/3.7a3pre * Unable to test nightly builds from 2010-03-01 to present (due to Bug 553053) * BROKEN: a current debug build, with either... - Bug 547062's change reverted (per 553053 comment 1) or... - Bug 553053's patch applied (attachment 433311 [details] [diff] [review]) (per bug 553053 comment 5) So, this broke sometime between 2010-03-01 and yesterday. (though it's not visible unless you revert or apply a patch, as described above) I'm assuming bug 553053 will land on m-c soon, and then this bug will become visible on nightly builds. (which will be an improvement from the current situation, but is still broken w.r.t. our behavior up to March 1st.)

(In reply to comment #0) > STEPS TO REPRODUCE: > 1. Load Adobe "wonder" demo. URL: http://svg.kvalitne.cz/adobe/wonder.svg

I generated some intermediate hg clones & applied bug 553053's patch to them, to track this down. Looks like this was regressed by http://hg.mozilla.org/mozilla-central/rev/6776f09c1bc6 (bug 548899). That checkin effectively switched how we notify "animated value of transform changed", in nsSVGTransformSMILAttr::SetAnimValue. - Previously, we used DidModify on the transform attribute itself (which is what gets called when the transform attribute is actually changed). - Now, we effectively use GetPrimaryFrame()->AttributeChanged(..., nsGkAtoms::transform, ...); Perhaps ClipPath elements don't have a primary frame? That, or the frame doesn't respond correctly to AttributeChanged() calls...

(In reply to comment #2) > Perhaps ClipPath elements don't have a primary frame? Wrong, looks like there should be a nsSVGClipPathFrame in play. > That, or the frame > doesn't respond correctly to AttributeChanged() calls... Could still be this. I'm going to step through what happens here in a little bit, and I'll report back when I know more...

I wonder if nsSVGClipPathFrame now needs an AttributeChanged that calls nsSVGUtils::NotifyChildrenOfSVGChange when it gets a transform attribute change now.

That sounds right. Here's a reduced testcase for this. It should show a strip of green moving smoothly to the right. Instead, with a current mozilla-central build, the strip of green is frozen until you mouseover it (which triggers a repaint, at least on my system). (Note that today's nightly build will show nothing, because it doesn't include bug 553053's fix.)

Yeah, right now it's using the implementation "nsFrame::AttributeChanged", which is a no-op. We definitely need to override that.

Here's a fix to do what longsonr suggested in comment 4. Reftest included. (I verified that it fails pre-patching & passes post-patching.)

Thanks for the review! I'm going to wait until tomorrow at the earliest to land this, so that we get at least one nightly that includes Bug 553053's fix but lacks this fix. (That way, this bug will be visible in at least one nightly, and it will be easier to determine the cause of any (unanticipated) regressions that arise from this bug and/or bug Bug 553053.)

Landed: http://hg.mozilla.org/mozilla-central/rev/20d8a5a92920