Bug 709384. Manage our scheduled state better when animation frame requests are canceled. r=roc

2011-12-15 08:53:06 -05:00 · 2011-12-15 08:53:06 -05:00 · d7c7b61b9f
--- a/content/base/crashtests/709384.html
+++ b/content/base/crashtests/709384.html
@ -0,0 +1,5 @@
+<!DOCTYPE html>
+<script>
+  mozCancelRequestAnimationFrame(mozRequestAnimationFrame(function() {}));
+  mozRequestAnimationFrame(function() {});
+</script>
--- a/content/base/crashtests/crashtests.list
+++ b/content/base/crashtests/crashtests.list
@ -102,3 +102,4 @@ load 700090-1.html
 load 700090-2.html
 load 700512.html
 load xhr_html_nullresponse.html
+load 709384.html
--- a/content/base/src/nsDocument.cpp
+++ b/content/base/src/nsDocument.cpp
@ -8095,11 +8095,12 @@ void
 nsIDocument::CancelFrameRequestCallback(PRInt32 aHandle)
 {
  // mFrameRequestCallbacks is stored sorted by handle
-  mFrameRequestCallbacks.RemoveElementSorted(aHandle);
-
-  // Not going to worry about unscheduling our refresh driver
-  // callback.  It'll just be a no-op when it happens, if we have no
-  // more frame request callbacks.
+  if (mFrameRequestCallbacks.RemoveElementSorted(aHandle) &&
+      mFrameRequestCallbacks.IsEmpty() &&
+      mPresShell && IsEventHandlingEnabled()) {
+    mPresShell->GetPresContext()->RefreshDriver()->
+      RevokeFrameRequestCallbacks(this);
+  }
 }

 nsresult