Allow suspension prior to reaching kHaveFutureData.

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 5889a8f795c07f25f1ac9d8627c0aa344c51fb03..9c9e89b96d91e3cb386def79fc24e0d6c3e95da4 100644
--- a/third_party/WebKit/Source/core/html/HTMLMediaElement.cpp
+++ b/third_party/WebKit/Source/core/html/HTMLMediaElement.cpp
@@ -3175,6 +3175,12 @@ void HTMLMediaElement::updatePlayState()
             mediaControls()->playbackStopped();
     }
 
+    if (webMediaPlayer()) {
+        // Always notify of playback state changes; this information is used by
+        // the WebMediaPlayer to optimize resource consumption.
+        webMediaPlayer()->setPlaybackState(m_playing || !m_paused ? WebMediaPlayer::PlaybackState::Playing : WebMediaPlayer::PlaybackState::Paused);

[sandersd (OOO until July 31), 2016/08/30 18:40:18]

This way of sending the information somewhat implies that WMPI should also be
reading the state at construction time, instead of assuming paused.

Do we get a strong guarantee that WMPI finds out the state shortly after
construction from this?

[DaleCurtis, 2016/08/30 21:56:04]

Added set during startPlayerLoad() -- otherwise I think you're right this could
get out of sync.

+    }
+
     if (layoutObject())
         layoutObject()->updateFromElement();
 }