[Blink>Media] Fix a crash in autoplay caused by delayed visibility observation

third_party/WebKit/Source/core/html/HTMLMediaElement.cpp

Index: third_party/WebKit/Source/core/html/HTMLMediaElement.cpp
diff --git a/third_party/WebKit/Source/core/html/HTMLMediaElement.cpp b/third_party/WebKit/Source/core/html/HTMLMediaElement.cpp
index a43e6d66f8ee0b4559685b200eeaa299fc9e97a8..caa74795f478b099fb9287f3227341133efff92a 100644
--- a/third_party/WebKit/Source/core/html/HTMLMediaElement.cpp
+++ b/third_party/WebKit/Source/core/html/HTMLMediaElement.cpp
@@ -4005,6 +4005,10 @@ EnumerationHistogram& HTMLMediaElement::showControlsHistogram() const {
 void HTMLMediaElement::onVisibilityChangedForAutoplay(bool isVisible) {
   if (!isVisible)
     return;
+  // Visibility change might be notified after stopping the observer, as it is a
+  // delayed task. Abort the steps if this happens.
+  if (!m_autoplayVisibilityObserver)
+    return;

[mlamouri (slow - plz ping), 2017/02/06 12:55:43]

Why should we early return here? Shouldn't we instead do the check before
calling stop?

[Zhiqiang Zhang (Slow), 2017/02/06 14:17:14]

I think we should assume visibility change will never be fired after we stop the
observer.

Here's a corner case if we do the null-check before stop():
1. A video with autoplay attribute gets loaded and becomes visible (however the
signal is delayed)
2. The page calls video.muted = true
3. The page calls video.muted = false
4. The visibility change signal is delivered

In this situation, the video will end up to be playing, however it is expected
to be paused.

[mlamouri (slow - plz ping), 2017/02/07 12:36:27]

I see. That makes sense :)

 
   if (shouldAutoplay()) {
     m_paused = false;