I'm filing this bug on adding an about:config flag to let users toggle SMIL support on/off. (Then, we can hopefully default-disable SMIL via this about:config flag and turn on the "--enable-smil" build-time flag in nightly builds. That would allow interested users to experiment with SMIL without needing to generate custom builds.)

Might want to think about moving from --enable-smil to --disable-smil either as part of this patch or a follow-up.

(In reply to comment #1) > Might want to think about moving from --enable-smil to --disable-smil either as > part of this patch or a follow-up. I've posted a patch that does this in bug 473705.

Here's a simple WIP patch for this. So far, it does the following: - Adds a pref called 'svg.smil.enabled', which defaults to false - When a Document is initialized, it takes a snapshot of this pref's current value - If this snapshotted value is false, the Document will refuse to create a nsSMILAnimationController (and will return 'null' to any GetAnimationController() calls) This disables the main SMIL animation / sampling code (for any documents initialized while the pref is disabled). It also disables all nsSMILValue-parsing code, because currently all nsSMILValue parsing is done at sample-time. For thoroughness, we should probably disable initialization of nsSVGSVGElement::mTimedDocumentRoot, too, though I'm not yet sure of the best way to do that. (I want to think a bit more about cases with dynamic SVG element creation / transfer between documents, particularly when one document is created while SMIL is on and the other is created when SMIL is off)

(In reply to comment #3) > For thoroughness, we should probably disable initialization of > nsSVGSVGElement::mTimedDocumentRoot, too, though I'm not yet sure of the best > way to do that. This is now taken care of via Bug 481562. If SMIL is turned off via 'svg.smil.enabled' in patch v1 here, then nsDocument::GetAnimationController() will return null (via this bug's patch), and that'll make Bug 481562's patch disable initialization of mTimedDocumentRoot. Yay!

This stops animation from working but the DOM APIs are still present and detectable. That might be bad if people use them to do feature detection. Can we also dynamically disable creation of SMIL element types at least, like we do for SVG in general?

Ok, this new patch maintains a single global smil-enabled boolean (like we do with SVG enabled-ness). This boolean controls... (a) whether we allow ourselves to create animation-related SVG nodes in nsSVGElementFactory.cpp (b) whether we return NS_ERROR_NOT_IMPLEMENTED in animation-related API functions on <svg> elements (c) whether we recognize "TimeControl" in nsGenericElement::InternalIsSupported() (d) whether we allow nsDocument to create an animation controller Part (d) is basically the same as in my previous patch, but parts a/b/c are new and should block any feature detection when SMIL is disabled.

Here's a version of patch v2 with whitespace-changes excluded. (since a number of the changes are simply adding "if (NS_SMILEnabled()) {" above a block of code)

BTW, I've confirmed that we pass all SMIL reftests with this patch applied (and with the svg.smil.enabled pref turned on).

Pushed attachment 366441 [details] [diff] [review]: http://hg.mozilla.org/mozilla-central/rev/ba3ad61aa365

This is mentioned in several places in the SVG documentation, as well as in this new article that's under construction: https://developer.mozilla.org/en/SVG_animation_%28SMIL%29_in_Firefox

We've just turned off support in 3.6 (bug 512594) Animation is now 1.9.3 only.