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

UNCONFIRMED
Unassigned

Status

()

Core
SVG
UNCONFIRMED
7 years ago
6 years ago

People

(Reporter: Marek Raida, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(3 attachments)

(Reporter)

Description

7 years ago
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).
(Reporter)

Comment 1

7 years ago
Created attachment 474680 [details]
Testcase showing broken behavior of svg:use
Probably a duplicate of bug 265895
Depends on: 265895
Duplicate of this bug: 623677
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. :))
OS: Windows 7 → All
Hardware: x86 → All
Version: unspecified → Trunk
(Reporter)

Comment 5

7 years ago
Created attachment 502281 [details]
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.
(Reporter)

Comment 6

7 years ago
Created attachment 502333 [details]
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...
(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

6 years ago
(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.
(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

6 years ago
(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.
You need to log in before you can comment on or make changes to this bug.