Prevent more script-observable cases of HTMLMediaElement GC

Source/core/html/HTMLMediaElement.cpp

Index: Source/core/html/HTMLMediaElement.cpp
diff --git a/Source/core/html/HTMLMediaElement.cpp b/Source/core/html/HTMLMediaElement.cpp
index 297200ac63334d0e5ee4d36028048b6a16e59a94..306777c76b6a4e33b9d88e664fa7acfec7fa47f7 100644
--- a/Source/core/html/HTMLMediaElement.cpp
+++ b/Source/core/html/HTMLMediaElement.cpp
@@ -3468,7 +3468,22 @@ void HTMLMediaElement::stop()
 
 bool HTMLMediaElement::hasPendingActivity() const
 {
-    return (hasAudio() && isPlaying()) || m_asyncEventQueue->hasPendingEvents();
+    if (m_shouldDelayLoadEvent)
+        return true;
+
+    if (m_networkState == NETWORK_LOADING)
+        return true;
+
+    if (potentiallyPlaying())

[Ken Russell (switch to Gerrit), 2014/09/11 18:20:56]

Consider the case where a video is set to loop and then to play. Then a page
navigation occurs and ActiveDOMObject::stop is called against the video element.
Will that cause potentiallyPlaying() to start returning false so that the
HTMLMediaElement will ultimately be GC'd? (Or do ActiveDOMObjects have some
other mechanism to prevent them from leaking once the page that contained them
is destroyed?)

[acolwell GONE FROM CHROMIUM, 2014/09/11 19:02:24]

I believe it we add an m_readyStateMaximum = HAVE_NOTHING to userCancelledLoad()
near the m_readyState assignment we'll cover most of the cases. I'm still trying
to figure out what the right thing to do is if m_completelyLoaded is true
because that assignment is skipped in that case.

[philipj_slow, 2014/09/12 14:05:20]

I'll add "if (!document().isActive()) return false" at the top of
hasPendingActivity() as a catch-all for this kind of thing. Sound OK?

+        return true;
+
+    if (m_seeking)
+        return true;
+
+    if (m_asyncEventQueue->hasPendingEvents())
+        return true;
+
+    return false;
 }
 
 void HTMLMediaElement::contextDestroyed()