1373136 - SMIL animations no longer cloned for SVG <use> element copies

Status: RESOLVED WORKSFORME

(Core :: SVG, defect, P3)

Description

[Amelia Bellamy-Royds]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36

Steps to reproduce:

- Create an SVG element that is animated with an SVG/SMIL animation element (e.g., <animate>, <set>, <animateMotion>, <animateTransform>)
- Create a <use> element clone of the first element

Demo: https://codepen.io/AmeliaBR/pen/wezbyY?editors=1000


Actual results:

The SVG/SMIL animations are not applied on the <use> element clone.


Expected results:

The animation effects should be propagated to the clone.

This used to work when the animation element was a child of the cloned element.  Firefox has always had problems when the animation was applied to an element using a cross-reference to an `id`.  Now, neither works.

The regression happened in Firefox 31 (i.e., Firefox 30 correctly clones the child animations, although not the cross-reference one).

Note that this bug will hide #537987, which is an old bug about <use> elements and animation of the `display` property.  I couldn't find any other relevant bug reports.

Comment 1

[Robert Longson [:longsonr]]

Can you use http://mozilla.github.io/mozregression/ to narrow down the range please? Since you know it's 31 you should be able to plug that information into the regression finder to make it really quick to do.

Comment 2

[Amelia Bellamy-Royds]

Oh, and here's a weird thing (I just added it to the linked CodePen): if the <use> is inside a <clipPath> or <mask>, then the animation works fine!  (Or at least, the ones that are child elements of the <circle> do.)  So maybe the issue isn't in the cloning of the animation, but in the update chain that tells the browser it needs to repaint & re-layout the <use>?

Comment 3

[Amelia Bellamy-Royds]

(In reply to Robert Longson from comment #1)
> Can you use http://mozilla.github.io/mozregression/ to narrow down the range
> please? Since you know it's 31 you should be able to plug that information
> into the regression finder to make it really quick to do.

I can try that at some point, but don't have time to install & learn new software today, so if anyone else can run it that would be appreciated.

Comment 4

[Thomas Wisniewski]

I just ran mozregression on my linux64 box and was able to narrow the range down to:

>INFO: Got as far as we can go bisecting nightlies...
>INFO: Last good revision: c962bde5ac0b (2014-04-22)
>INFO: First bad revision: ac376a4e8174 (2014-04-23)
>INFO: Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c962bde5ac0b&tochange=ac376a4e8174

Bug 991545 stands out, but I just compiled moc-central with a revert for that patch, and the animations are still not working.

Comment 5

[Amelia Bellamy-Royds]

Thanks for the bisect, Thomas.

The problem happens for both transform animations and paint animations, so it's not just a matter of offloading an optimized animation and then not being able to query it for the clone.  

(Compare with #1118710 and #1178297, where optimized CSS or JS animations aren't being reflected in a mask or clipPath.  Here, it's the opposite problem: the mask and clipPath are correctly updating to match the SMIL animations, but the directly-rendered `<use>` is not.)

I ran the test case (https://s.codepen.io/AmeliaBR/debug/wezbyY) with paint flashing on in Dev Tools, and the non-animated clone was still flashing, so it's still getting the notification to re-paint each frame, it's just not querying the animated values when it does.

Comment 6

[Ciprian Muresan [:cmuresan], Formerly of Ecosystem QA - please needinfo @mcoman for things regarding the team]

Removing the regressionwindow-wanted flag because one was already provided in Comment 4.

Comment 7

[Daniel Holbert [:dholbert]]

Attachment: testcase 1 (from reporter)

Here's a copy of the testcase, for archival purposes.

Comment 8

[Daniel Holbert [:dholbert]]

Attachment: testcase 1 (from reporter)

(er, sorry -- previous version had a stray <svg> tag crufting it up, due to a copypaste typo.)

Comment 9

[Daniel Holbert [:dholbert]]

This is wontfix for 57 since we're near the end of that cycle on Nightly, but it'd be good to get this fixed sometime!

(In reply to Thomas Wisniewski from comment #4)
> Bug 991545 stands out, but I just compiled moc-central with a revert for
> that patch, and the animations are still not working.

(Cool -- tentatively marking as regression from bug 991545 -- I agree that looks like the most likely cause, in your pushlog. I'm assuming your local build was otherwise up-to-date, with that patch reverted on top of up-to-date code.  If that's the case, I'm not too surprised that the revert didn't fix things -- it's likely other stuff has changed to make it more complex to get to a working state.)

Comment 10

[Robert Longson [:longsonr]]

Seems OK now.