User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:2.0b6pre) Gecko/20100902 Firefox/4.0b6pre Build Identifier: Mozilla/5.0 (X11; Linux x86_64; rv:2.0b6pre) Gecko/20100902 Firefox/4.0b6pre If you have an SVG element inside a SVG document, the SVG element is not rendered if you try to change it's X and Y attributes with a script or a SMIL animations Reproducible: Always Steps to Reproduce: 1. See the 3 tests case Actual Results: For the first TC : You can see a red square and a blue square For the second TC : You can see a red square and a green square For the third TC : You can see a red square and a green square Expected Results: For the first TC : You should see a green square and a blue square For the second TC : You should see a green square moving from right to left to overlap the red square and showing the blue square For the third TC : You should see a green square moving from right to left to overlap the red square and showing the blue square The first TC is a simple change made with javascript on the window load event The second TC is a scripted animation that update the X attribute of the SVG element every 20ms The third TC is a SMIL animation that update the X attribute of the SVG element during 3s. For each test case, if you force a reflow (by changing the size of your window for exemple), you should be able to see the SVG element to it's current position. Why 3 test case ? The first is the simplest test case. The second is the animated version of the first. This due to webkit that pass the first test but have a bug when there is an animation (there are rendering artifacts) The third test case is here to demonstrate that script animations and declarative animations act the same on SVG element. Opera pass all those tests without any problems.

FYI. Firefox 3.6 passes first and second tests.

My mozilla-central nightly fails all 3 tests. Adding regression keywords.

Regression range for the first test: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=af0f0615944e&tochange=4b18d31e83f4 Second test has the same range. now the problem is... nothing in there jumps out at me. Daniel, any ideas?

Ah, perhaps bug 545550?

Which _did_ remove some notifications....

Yup, that sounds like a likely candidate, then. Putting this on my list.

Is this fixed by my patch in bug 571863?

(In reply to comment #10) > Is this fixed by my patch in bug 571863? No, but it gets us a step closer. Your patch doesn't affect testcase 1, but it partly fixes #2 & #3. Behavior on testcases 2/3: - Opera: Green rect slides leftwards, covering red & revealing blue - m-c: No animation -- unmoving [redrect] [greenrect] - m-c + patch: Right edge of green rect collapses towards its left edge, making it disappear. (behavior is as if we were animating its width to 0)

Testcases 1 & 2 both become fixed if I add back this line aSVGElement->DidChangeLength(mAttrEnum, aDoSetAttr); to nsSVGLength2::SetBaseValueString(). (see also bug 601934 comment 3)

(In reply to comment #12) > Testcases 1 & 2 both become fixed if I add back this line > aSVGElement->DidChangeLength(mAttrEnum, aDoSetAttr); > to nsSVGLength2::SetBaseValueString(). Is that with or without bug 571863?

Without. Adding that patch gets me the partial-fix on testcase 3 that I mentioned in comment 11.

The key thing that nsSVGSVGElement::DidChangeLength gets us (and that we lack without it) is a call to InvalidateTransformNotifyFrame(). If I add the DidChangeLength call (per comment 12) but skip its call to InvalidateTransformNotifyFrame, the bug remains.

Testcase 3 becomes completely fixed if I simply add an impl of nsSVGSVGElement::DidAnimateLength

(to call InvalidateTransformNotifyFrame, that is)

Here's the fix so far. Still todo: - Make reftests from this bug's testcases - I think we need a DidAnimateEnum() method, as noted in the patch. (First I want to make a test that's broken due to the current lack of DidAnimateEnum, though.) - I fear that all the other "// We don't need to call DidChange* here" comments from http://hg.mozilla.org/mozilla-central/rev/165e0bfa8352 may be incorrect, too -- at least, the ones in places that could be targeting a custom impl of DidChange* (like nsSVGSVGElement's DidChange* methods, all of which call InvalidateTransformNotifyFrame)

Comment 16 is the wrong thing to do. I'll change bug 571863 to work.

bug 571863 should now fix testcase 3 on its own.

OK bug 571863 now completely fixes testcase 2 and testcase 3 on its own.

I think it fixes the hedgehog too unless I'm missing something.

Oh and it fixes testcase 1 as well so that's a full house :-)

(In reply to comment #21) (In reply to comment #22) (In reply to comment #23) Yay, that's great news!