1105912 - animateMotion doesn't work with calcMode="spline", keyTimes, & no keyPoints (and complicated path)

Status: RESOLVED INVALID

(Core :: SVG, defect)

Description

[Daniel O'Connor]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:33.0) Gecko/20100101 Firefox/33.0
Build ID: 20141113143407

Steps to reproduce:

See: http://codepen.io/danoc/pen/ByNMGL

To reproduce:

1) Open the URL in the latest Firefox (I'm currently on 33.1.1)
2) Notice that the animation does not load
3) Replace `#path` with `#path-simplified` on the `mpath` element below to see this work in Firefox on a simpler path


Actual results:

The animation did not load and 3/4 of the circle was hidden on the top-left corner of the screen.


Expected results:

The circle should animate along the path with custom easing.

Comment 1

[Daniel O'Connor]

It also doesn't seem to follow the path when using `#path-simplified`, but I guess that is another bug?
https://www.dropbox.com/s/h0n4xzxuk71de9x/Screenshot%202014-11-27%2022.32.10.png

Comment 2

[Tom Klein]

Attachment: complicated path testcase.html

Here's a standalone version of the complicated path testcase.

The only substantive thing I changed was to add a keyTime for each vertex in the referenced path, and then enough keySplines to go with the keyTimes (the reporter's testcase had keyTimes="0;1").

I'm not sure, but I think that's the expected behavior: i.e. that there must be the same number of keyTimes as there are vertices in the motion path (that basically there's an implied "values" list with one entry for each vertex of the motion path).  Daniel, can you comment on that?  (Chrome behaves differently, which may be part of the confusion here.)

(Note that the original path (copied to this testcase) has an unnecessary "z" at the end of the path which adds another vertex (and therefore keyTime) to the path.)

Comment 3

[Tom Klein]

Attachment: simplified path testcase.html

Here's a standalone version of the original path-simplified path.  It works for me.

Daniel O'Connor, is it working for you now or do you still see the circle wander off the path?

Comment 4

[Tom Klein]

A couple more things:

1) Just to be clear, I meant Daniel Holbert in comment 2. :)

2) Daniel O'Connor: assuming that my explanation in comment 2 is correct, then I think seeing the circle appear in the upper left corner with only 1/4 of it visible is also expected behavior since in that case the animation is in error, and so the circle is just drawn without the animation being applied.  Since the original circle specified cx="0" and cy="0", the unanimated circle appears with its center at (or near, depending on margins etc) the upper left corner of the screen.

Comment 5

[Daniel Holbert [:dholbert]]

Thanks for the triage, Tom, and for the bug report, Daniel!

(In reply to Tom Klein from comment #2)
> I'm not sure, but I think that's the expected behavior: i.e. that there must
> be the same number of keyTimes as there are vertices in the motion path
> (that basically there's an implied "values" list with one entry for each
> vertex of the motion path).  Daniel, can you comment on that?

This is exactly correct. RE the implied "values" list -- that's described here in the spec:
 # if attribute ‘keyPoints’ is not provided, the number of values
 # is defined to be the number of points defined by the path,
 [...]
 # If specified, ‘keyPoints’ causes ‘keyTimes’ to apply to the
 # values in ‘keyPoints’ rather than the [...] points on the ‘path’
 # attribute.

So -- if keyPoints is not specified, then the keyTimes correspond to the intermediate points in the path (as an implied "values" list). And if the keyTimes does not have the same number of entries as there are corresponding values, then "the document is in error" [per keyTimes documentation], which we react to by failing to animate.

Here's a tweaked version of the original Codepen, simply changed to add keyPoints="0;1" to establish the points that correspond to the keyTimes (instead of forcing them to come from the motion path).  This is the spec-compliant way to get the behavior that the reporter is looking for:
  http://codepen.io/anon/pen/zGXpLQ
This explicitly defines two animation points (one at the beginning & one at the end), and then the keyTimes values can be correctly matched to those points, and the keySplines attribute tells us how to interpolate between them.

(In reply to Tom Klein from comment #4)
> 2) Daniel O'Connor: assuming that my explanation in comment 2 is correct,
> then I think seeing the circle appear in the upper left corner with only 1/4
> of it visible is also expected behavior since in that case the animation is
> in error, and so the circle is just drawn without the animation being
> applied.

Exactly right, yeah.

Comment 6

[Daniel Holbert [:dholbert]]

(In reply to Daniel O'Connor from comment #1)
> It also doesn't seem to follow the path when using `#path-simplified`, but I
> guess that is another bug?
(In reply to Tom Klein from comment #3)
> Here's a standalone version of the original path-simplified path.  It works
> for me.

I can reproduce the "doesn't seem to follow the path" issue that Daniel describes, if I use Firefox 33.  But it, works correctly for me in Firefox 38 and newer (and probably some earlier versions as well; I only tested 33, 38, and trunk).  I'm assuming Tom tested it using a newish Firefox version.

So that part was indeed a bug, & was fixed elsewhere at some point.

Comment 7

[Daniel Holbert [:dholbert]]

SVG 1.2 Tiny is a bit more explicit about what's supposed to happen here.

It describes this validity requirement for keyTimes (and to ignore the animation if it doesn't match the requirements):
 # If a list of 'keyTimes' is specified, there must be exactly as many
 # values in the 'keyTimes' list as in the 'values' list.
 [...]
 # If the 'keyTimes' attribute has a value that doesn't conform to the
 # above requirements the 'keyTimes' attribute has an unsupported value
 # and is processed as if the attribute had not been specified. 
 http://www.w3.org/TR/SVGMobile12/animate.html#KeyTimesAttribute

And the "'values' list" here means points on the path, as described here:
 # When an 'animateMotion' element has a 'calcMode' of [...] 'spline',
 # and if the 'keyPoints' attribute is not specified, the number of
 # values is defined to be the number of points defined by the path
http://www.w3.org/TR/SVGMobile12/animate.html#AnimateMotionElement

So, we're exactly following the spec's requirements here, which I think means this is INVALID.

Comment 8

[Daniel Holbert [:dholbert]]

[Canceling needinfo from comment 3, since I think I answered it in comment 6.]

Comment 9

[Daniel O'Connor]

Great, thank you!