1.16 KB, image/svg+xml
1.36 KB, text/plain
12.40 KB, application/xml
1.00 KB, patch
|Details | Diff | Splinter Review|
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:2.0) Gecko/20100101 Firefox/4.0 Build Identifier: 4.0 final This final animation is running fine: http://towerofbabel.free.fr/stroke%20order/vertical2.svg When you click on the page, the animation resets and re-runs. However, the exact same animation doesn't work anymore when a XSL transformation is involved: http://towerofbabel.free.fr/stroke%20order/vertical3.svg Yet, both versions work fine in Opera. Actually vertical2.svg is what I got from vertical3.svg when ran through "Web Developer" > "View generated source". Reproducible: Always Steps to Reproduce: 1. open vertical2.svg 2. in another tab, open vertical3.svg Actual Results: 1. all's working fine with the 1st file 2. only the initial SVG drawing is rendered, not the subsequent animation with the 2nd file Expected Results: both files should behave like the 1st file
Confirmed on Build identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0) Gecko/20100101 Firefox/4.0
Status: UNCONFIRMED → NEW
Ever confirmed: true
http://www.w3.org/TR/SVG/animate.html#RelationshipToSMILAnimation says... From the SMIL Animation requires that the host language define the meaning for document begin and the document end. Since an ‘svg’ is sometimes the root of the XML document tree and other times can be a component of a parent XML grammar, the document begin for a given SVG document fragment is defined to be the exact time at which the ‘svg’ element's SVGLoad event is triggered. The SVG specification defines the onload handler as being called when the element is parsed. In this case, there is no parsing going on: you're directly synthesizing SVG DOM nodes. You'd get the same effect if you built the DOM tree involved using createElementNS. And now you're thinking, so I why do some other browsers work.... XSLT has two primary modes of operation. Either DOM nodes are produced directly as the output of the transform, or they're produced, serialized, then parsed. Per the current definitions in the SVG spec, the latter would fire load events. Some browser XSLT engines operate in the latter mode some or all the time. In the former mode, the operation really does look just like building a DOM with createElementNS then adopting it into another document.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → INVALID
(In reply to comment #5) > The SVG specification defines the onload handler as being called when the > element is parsed. In this case, there is no parsing going on: you're directly > synthesizing SVG DOM nodes. You'd get the same effect if you built the DOM > tree involved using createElementNS. For SVG trees created by script we trigger the animation when the tree gets bound to the document tree. Code: http://mxr.mozilla.org/mozilla-central/source/content/svg/content/src/nsSVGSVGElement.cpp#214 http://mxr.mozilla.org/mozilla-central/source/content/svg/content/src/nsSVGSVGElement.cpp#1088 Test case: http://brian.sol1.net/svg/tests/deferred-tree.xhtml Opera does likewise. Chrome doesn't seem to. Haven't tested a recent WebKit trunk though. Not sure what ought to happen for XSLT output.
Principle of least surprise for XSLT would be to run the animation; certainly if we do for normal script insertions. Why is that not happening here? Does XSLT create nodes with aFromParser true or something?
I guess this is the same as bug 386856.
nodes seem to be created with FromParser set to FROM_PARSER_XSLT (parents) and sometimes FROM_PARSER_FRAGMENT (children), although the children get created as parents themselves too. This results in mStartAnimationOnBindToTree being set false (http://mxr.mozilla.org/mozilla-central/source/content/svg/content/src/nsSVGSVGElement.cpp#214) and then this does nothing (http://mxr.mozilla.org/mozilla-central/source/content/svg/content/src/nsSVGSVGElement.cpp#1088)
Oh, fromparser isn't a boolean anymore.... We should consider setting mStartAnimationOnBindToTree to true for both XSLT and FRAGMENT, no? Otherwise, wouldn't animation starting also fail if the SVG is created via innerHTML?
I don't think this is INVALID either way, so reopening. Ideally I think the XSLT code, when run by the XMLContentSink due to an <?xml-stylesheet?> should produce notifications as similar to the XML sink as possible (in fact, I'd love for the XSLT code to generate the DOM by calling into an XML sink). I know that at times we have missed DidCreateChildren-type notifications. Are we still?
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
FWIW fromParser used to be a boolean, became an int in Bug 569538 which then became an enum in Bug 594339.
OS: Windows XP → All
Hardware: x86 → All
Version: unspecified → Trunk
Attachment #521453 - Attachment mime type: image/svg+xml → text/plain
Attachment #671201 - Attachment is obsolete: true
This seems to work but I can't get a reftest to work. Adding the xslt transform to the start of the file results in the animation seeming not to run. Clicking on the second link in comment 0 does now work however.
Attachment #671204 - Flags: review?(bzbarsky)
Comment on attachment 671204 [details] [diff] [review] patch r=me
Attachment #671204 - Flags: review?(bzbarsky) → review+
Status: REOPENED → ASSIGNED
https://hg.mozilla.org/mozilla-central/rev/27dbb2aaed4c Should this have a test?
Status: ASSIGNED → RESOLVED
Closed: 8 years ago → 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla19
You need to log in before you can comment on or make changes to this bug.