738574 - Animate does not animate related <use> elements

Status: NEW

(Core :: SVG, defect)

Description

[David White]

Attachment: Test SVG with animateTransform on path which is then cloned with <use>

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 (https://bugs.webkit.org/show_bug.cgi?id=81792). 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!)

Comment 2

[David White]

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?

Comment 3

[Robert Longson [:longsonr]]

It is and that's what that bug is about.

Comment 6

[david.dailey]

Hi all. Given that 1194728 is a duplicate, then it is highly likely, it would seem, that this is also:
http://cs.sru.edu/~ddailey/ello/BasicPuebloSpiral.svg
same symptoms -- reused stuff doesn't animate properly. See also instance at https://ello.co/ddailey/post/GwFlnDl399lyp_SVHhGM0A where embedded in social media.

Comment 8

[ccprog]

Attachment: Various animation elements and begin methods and their effect in <use>

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="trigger.click"
  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.

Comment 9

[ccprog]

I just found an even stranger behavior, see

https://gist.github.com/ccprog/ae3e2fa676cf902a1e33622e695acbb8

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.

Comment 11

[BugBot [:suhaib / :marco/ :calixte]]

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.

Comment 12

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

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.

Comment 13

[Robert Longson [:longsonr]]

Attachment: Bug 738574 part 1 - use SVGRenderingObserver to observe use elements so we can hook into SMIL animations r=emilio

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
SVGGraphicsElements).

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

Comment 14

[Robert Longson [:longsonr]]

Attachment: Bug 738574 part 2 - send mouse events to use target content r=emilio,smaug

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:

https://www.w3.org/Graphics/SVG/Test/20110816/harness/htmlObjectApproved/animate-interact-events-01-t.html

As does

https://bug738574.bmoattachments.org/attachment.cgi?id=608634

Depends on D187262

Comment 15

[Robert Longson [:longsonr]]

https://treeherder.mozilla.org/jobs?repo=try&revision=335e47b2cd0dd77fda20f91ef872e127fb6f91cd

Comment 16

[Robert Longson [:longsonr]]

https://treeherder.mozilla.org/jobs?repo=try&revision=7f33d684bc345022a2c2d613954d519348185fbe

Comment 18

[[:nickname]]

Problems:

• beginElement() having no effect on <use>: https://stackoverflow.com/q/79652232/
• begin="startButton.click" having no effect on <use> if the click event gets dispatched in the first line of JS code: https://stackoverflow.com/a/79652233/
• begin="startButton.click" having unpredictable effect on <use> if the click event gets dispatched inside requestAnimationFrame() (race condition?): https://stackoverflow.com/a/79652233/ , https://stackoverflow.com/revisions/79721729/12

Comment 19

[[:nickname]]

Methods like pauseAnimations() and setCurrentTime() affect each SVG individually even if several SVGs contain identical <use> elements.

This has a consequence that is difficult to notice but severely reduces the frame rate: Seeking to the same frame in all such SVGs is slow probably because Firefox probably computes interpolated coordinates (for example for d in <path>) redundantly for each SVG.

All this is different from Chrome's behavior.