Firefox3.1/SMIL Security Review: Difference between revisions

→‎Exported APIs: - switch ElementTimeControl interface to the one defined in SVG spec (better documented) rather than the one in the smil-animation spec
(→‎Exported APIs: - switch ElementTimeControl interface to the one defined in SVG spec (better documented) rather than the one in the smil-animation spec)
 
(3 intermediate revisions by 2 users not shown)
Line 25: Line 25:
== Exported APIs ==
== Exported APIs ==
* Please provide a table of exported interfaces (APIs, ABIs, protocols, UI, etc.)
* Please provide a table of exported interfaces (APIs, ABIs, protocols, UI, etc.)
** [http://www.w3.org/TR/2001/REC-smil-animation-20010904/#ElementTimeControl nsIDOMElementTimeControl.idl]
** [http://www.w3.org/TR/SVG11/animate.html#InterfaceElementTimeControl nsIDOMElementTimeControl.idl]
*** boolean beginElement()
*** boolean beginElement()
*** boolean beginElementAt(in float offset)
*** boolean beginElementAt(in float offset)
Line 131: Line 131:
* can specify lists of begin and end times
* can specify lists of begin and end times
** what if they don't have the same number of elements?
** what if they don't have the same number of elements?
*** <b>dholbert</b>: I misspoke about this during the security review.  What actually happens is this:
**** An animation needs one or more "begin" values and exactly one "dur" value. 
**** As time passes, we'll (re)start the animation each time we hit a "begin" value. 
**** If there's an "end" list, then each time we cross a time in the "end" list, we interrupt the current interval of the animation (if it's playing). (Upon interrupting, we either freeze the animation or remove its effects, depending on the value of the "fill" attribute)
**** Moreover, the largest "end" value defines a "final" end, at which point any subsequent "begin" values will not have any effect. (Note that you can get around this by putting the special string "indefinite" in the end list -- this value is never reached in time.)
*** So, the number of "begin" vs. number of "end" elements doesn't really matter.  Hopefully this is more clear.
** what if they are misordered? Do they match by index in the given lists or do the begins run until the next specified end?
** what if they are misordered? Do they match by index in the given lists or do the begins run until the next specified end?
*** <b>dholbert</b>: List-order doesn't matter in the begin / end lists -- only temporal order.  Basically, each "begin" triggers an instance of the animation (with duration "dur"), and the run will be interrupted by any "end" times encountered during it run. (See answer to previous question for more detail)
* integer overflows if images get too big? translated way offscreen?
* integer overflows if images get too big? translated way offscreen?
** SVG keeps things in floating point, cairo's interface is floating point
** SVG keeps things in floating point, cairo's interface is floating point
** cairo does the conversion into actual images
** cairo does the conversion into actual images
* calcModes: discrete, spline, paced, linear
* spec says there should be animation events, but we don't fire them. Should we ever do that we would need to be careful.
* spec says there should be animation events, but we don't fire them. Should we ever do that we would need to be careful.
* animation nodes can be moved from element to element -- test
* animation nodes can be moved from element to element -- test
* "fill" values: freeze, remove
* tests
* tests
** calcModes: discrete, spline, paced, linear
** "fill" values: freeze, remove?
** closing the window right after setting current time
** closing the window right after setting current time
** destroy iframe while animating
** destroy iframe while animating
Confirmed users
489

edits