Open Bug 738574 Opened 12 years ago Updated 24 days ago

Animate does not animate related <use> elements


(Core :: SVG, defect)

11 Branch




(Reporter: david, Assigned: longsonr)


(Blocks 9 open bugs)



(4 files)

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:11.0) Gecko/20100101 Firefox/11.0
Build ID: 20120310010446

Steps to reproduce:

Created SVG with a path with a animateTransform child element linked to mouseover (black circle). Cloned that path several times (red, green and blue circles).

Tried mouse over each element in turn (original path and use elements)

Actual results:

mouseover on use elements animates individually, as expected.

However, mouseover on original path only animates that path and not use elements

Expected results:

Spec isn't clear on this but I anticipated that mouseover on original path would animate use elements since they mimic all properties of the original.

This came from testing a bug in Webkit ( With webkit mouseover on <use> calls all sibling <use> elements to animate, which is definately incorrect.

I would like correct behaviour on triggering animation on a element which is cloned with <use> to be agreed and implemented the same across browsers. (please!)
Closed: 12 years ago
Resolution: --- → DUPLICATE
Thank you, Robert. I did search but didn't come across this one.

Is the compliant behaviour then that animating an object should animate all related <use> clones?
Resolution: DUPLICATE → ---
It is and that's what that bug is about.
Closed: 12 years ago12 years ago
Resolution: --- → DUPLICATE
Ever confirmed: true
Resolution: DUPLICATE → ---
Assignee: nobody → longsonr
Assignee: longsonr → nobody
Summary: Animate on a path does not animate relate use elements → Animate does not animate related <use> elements
Hi all. Given that 1194728 is a duplicate, then it is highly likely, it would seem, that this is also:
same symptoms -- reused stuff doesn't animate properly. See also instance at where embedded in social media.
Wait for 2 seconds for the fixed-time animations. Click on the red bars to trigger animations.

Groups are
  animate   animateTransform
  set       animateMotion

Each group has
  first line: animationElement.beginElement()
  second line: begin=""
  third line: begin="2s"
  left column: animated element, right column: <use>

Whether the <use> element is animated differs between the animation elements, and it differs between the way the animation is started:

- <animate> and <set>: The <use> element is animated if the animation
  on its relative element is started at a fixed time or via a
  begin="otherElem.event" attribute, but not if it is started via the
  beginElement() method.
- <animateTransform> and <animateMotion>: The <use> element is never animated.
I just found an even stranger behavior, see

A path with an animateTransform is referenced in a <use> element twice: once, for direct rendering, and once as part of a mask. The animation is triggered with a begin="trigger.mouseover". The direct reference does not show the animation, but the masked element (which means, twice removed) has it working.
Severity: normal → S3

The severity field for this bug is relatively low, S3. However, the bug has 4 duplicates.
:jwatt, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(jwatt)

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Flags: needinfo?(jwatt)
No longer duplicate of this bug: 1782515
Depends on: 1843883, 1843945, 825254
Assignee: nobody → longsonr

SVGObserverUtils will allow us to observe all changes to the corresponding elements.

We turn off SMIL animation on the cloned elements as we'll now update from the corresponding
elements instead. That will keep all the animations in sync and stop us from having the
animations cancel when the animation elements are deleted from the clones (as they are not

As we're now dependent on the corresponding elements for animation we need to make sure we
don't throttle their animations.

Also fixes bug 575470 as we determine the correct target and relatedTarget for
events that are sent to the elements the use elements have cloned.

The following historic w3c test works too:

As does

Depends on D187262

Blocks: 866411
Blocks: 619509
Blocks: 595840
Blocks: 648529
Blocks: 1615948
No longer blocks: 866411
Depends on: 866411
Duplicate of this bug: 1864180
You need to log in before you can comment on or make changes to this bug.