595840 - JS Interface to SMIL events does not fire all related animations/actions in cloned nodes via svg:use

Status: UNCONFIRMED

(Core :: SVG, defect)

Description

[Marek Raida]

User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b6pre) Gecko/20100912 Firefox/4.0b6pre
Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b6pre) Gecko/20100912 Firefox/4.0b6pre

I believe this is svg:use related problem.
I'm re-using some element which contains SMIL animation. If is the animation triggered via offset value, it works properly and also cloned element's animation is processed. But if it is fired from javascript API using beginElement(), only the main animation is processed, but not the cloned one.

Reproducible: Always

Steps to Reproduce:
1. open attachment or file from URL http://svg.kvalitne.cz/mix/usebug.svg
2. there is navy rect translated and exists in cloned version as well
Actual Results:  
You see bigger rect animated twice, once fired from SMIL's offset value, and then from JS interface using beginElement().
There are two rectangulars but the small, cloned one using svg:use, is animated only once.

Expected Results:  
Both rectangulars should move / be animated twice.

It works as expected in Webkit/Presto.
Maybe it is related to https://bugzilla.mozilla.org/show_bug.cgi?id=467498, but I found not closely related bug (IMHO).

Comment 1

[Marek Raida]

Attachment: Testcase showing broken behavior of svg:use

Comment 2

[Robert Longson [:longsonr]]

Probably a duplicate of bug 265895

Comment 4

[Robert Longson [:longsonr]]

From dholbert in bug 623677...

I'm actually not sure that Firefox's behavior is wrong on this.

Basically, it sounds like you're saying the following:
  If an element is cloned via <use>, then DOM API calls
  (".beginElement()" in this case) on the original element
  should be repeated on all cloned copies of that element.

However, from a quick glance over the spec, I don't see any support for that
position.

The relevant chunk of spec is:
  http://www.w3.org/TR/SVG11/struct.html#UseElement

There is a paragraph or so about event propagation in the two subtrees (clone &
original), but I don't think that applies here, because there aren't really any
events involved here.

(I could easily be missing / misreading something, though. :))

Comment 5

[Marek Raida]

Attachment: Extended testcase

I still feel that current behavior is not consistent, so probably not correct.
FFX fires animation twice while other SVG implementations thrice.
First is triggered by scripting, which does not work and has been commented by Daniel.
Second is triggered by offset value and works even in cloned element.
Third is triggered by another animation and works in cascade in cloned element as well.
So the scripting API is the only one which behaves differently.

Comment 6

[Marek Raida]

Attachment: Even more extended test case

One more extended testcase, adding cases for testing also:
- accessKey values (o, a)
- user event values (mouseover over upper square)
- repeat event value (second repeat of upper square fill animation)

All of them work, so really trigger via JS API is the only case behaving differently... so I would really vote for aligning the behavior of them...

Comment 7

[Daniel Holbert [:dholbert]]

(In reply to comment #6)
> - user event values
[...]
> All of them work, so really trigger via JS API is the only case behaving
> differently

(Actually -- see bug 619509 for one instance where event-based animations in <use>-cloned content don't actually quite work how they're supposed to yet.  I'm pretty sure that one's a bug, whereas I'm still not sure this one is per comment 4 (though we may end up deciding to act on this anyway for interop purposes)).

Comment 8

[Leonid]

(In reply to Robert Longson from comment #4)
 
> However, from a quick glance over the spec, I don't see any support for that
> position.
> 
> The relevant chunk of spec is:
>   http://www.w3.org/TR/SVG11/struct.html#UseElement
> 
I had the opposite impression after reading the documentation, particularly the line where it says:
"Animations on a referenced element will cause the instances to also be animated."

I believe this means that anything regarding the animations should work synchronously on all instances of the original element. 

Voting for the bug.

Comment 9

[Robert Longson [:longsonr]]

(In reply to Leonid from comment #8)
> I had the opposite impression after reading the documentation, particularly
> the line where it says:
> "Animations on a referenced element will cause the instances to also be
> animated."
> 

That'a bug 619509 rather than this one.

Comment 10

[Leonid]

(In reply to Robert Longson from comment #9)

> That'a bug 619509 rather than this one.

Not really. The mentioned bug states that animation triggers should flow from any instance to all others (which would be nice btw), and this bug as well as the line from the documentation i have mentioned state that when you programmatically trigger animation on an original (referenced) element then the animations should also trigger on all instances of the original.