Commit Graph

4 Commits

Author SHA1 Message Date
Brian Birtles
f94f91e8f8 Bug 1225699 part 7 - Keep effect properties when the ownerDocument of the element changes; r=smaug 2015-11-26 16:53:54 +09:00
Brian Birtles
6197fa649d Bug 1225699 part 6 - Use strong refs to store effects on their target elements; r=smaug
This is so that when we have code like:

  elem.animate({ opacity: 0 }, 1000)

the resulting Animation object is kept alive by |elem| based on the following
ownership chain:

  elem --(strong)--> KeyframeEffectReadOnly --(strong)--> Animation

Now, there is an ownership cycle introduced here because KeyframeEffectReadOnly
objects also store owning references to their target elements. This is broken
when the Animation finishes (if it does not fill forwards) or is cancelled
since either event will trigger a call to
KeyframeEffectReadOnly::UpdateTargetRegistration.

If the Animation fills forwards, the resource will not be released until
it is cancelled. For Animations corresponding to CSS Animations / CSS
Transitions this happens when the Element is unbound or when the corresponding
style property is updated causing the animation to be replaced or removed.

For the general case of script-generated animations, however, this cycle won't
be broken until the Element is unbound and all external references to the
Animation or KeyframeEffectReadOnly are dropped.

It's unfortunate that we can't more aggressively prune these objects but it's
what the spec currently says. I've posted to the mailing list[1] about this but
have yet to find a good solution.

[1] https://lists.w3.org/Archives/Public/public-fx/2015OctDec/0029.html
2015-11-26 16:53:54 +09:00
Brian Birtles
605fbf1ff0 Bug 1225699 part 2 - Add Add/RemoveEffect to EffectSet; r=smaug 2015-11-26 16:53:53 +09:00
Brian Birtles
4c409833ef Bug 1225699 part 1 - Add EffectSet class; r=smaug 2015-11-26 16:53:53 +09:00