Transition networkState back to NETWORK_IDLE on fetch if preload=none

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 3b781bf062425814208b18e67bcd5c3da9712c68..881e47b1ef83bd78bad759eb8ac16f115749044a 100644
--- a/Source/core/html/HTMLMediaElement.cpp
+++ b/Source/core/html/HTMLMediaElement.cpp
@@ -892,6 +892,15 @@ void HTMLMediaElement::loadResource(const KURL& url, ContentType& contentType, c
         if (!m_havePreparedToPlay && !autoplay() && m_preload == MediaPlayer::None) {
             WTF_LOG(Media, "HTMLMediaElement::loadResource : Delaying load because preload == 'none'");
             m_delayingLoadForPreloadNone = true;
+            // This implements the "optional" step 3 from the resource fetch algorithm.
+            // 1. Set the networkState to NETWORK_IDLE.
+            // 2. Queue a task to fire a simple event named suspend at the element.
+            changeNetworkStateFromLoadingToIdle();

[fs, 2014/06/09 16:12:23]

This means that we'll also fire a progress event - which could be a bad thing
(since no 'progress' will have actually taken place yet.)

[acolwell GONE FROM CHROMIUM, 2014/06/09 17:54:17]

I think we should avoid firing the progress event in this case. ISTM that the
progress event in this method should be conditional on
m_player->didLoadingProgress(). Otherwise just add an enum param that lets you
control whether the event is fired or not and update the various call sites.

[fs, 2014/06/10 12:36:24]

Added gating of 'progress' dispatch on m_player->didLoadingProgress.

+            // 3. Queue a task to set the element's delaying-the-load-event
+            // flag to false. This stops delaying the load event.
+            // 4. Wait for the task to be run.

[fs, 2014/06/09 16:12:23]

Neither queuing a nor waiting for a task here, which I presume means the load
event could end up being delivered within the current task. Don't know how much
to worry about that one. Would be nice to fix of course.

[acolwell GONE FROM CHROMIUM, 2014/06/09 17:54:17]

Why don't you just add a timer here to actually implement the queue a task
functionality?

[fs, 2014/06/10 12:36:24]

Done (PS3). But to facilitate the wait in step 4 some additional state was
needed, so I refactored the code a bit - hopefully it's not too big a change
(not a lot of "collateral damage").
Also ended up renaming from "delayed load" to "deferred load" (in part because
it easier to make the required changes) - will happily change that back to
'delayed' (or anything else, really) though.

+            setShouldDelayLoadEvent(false);
+            // Continued in startDelayedLoad().
         } else {
             startPlayerLoad();
         }
@@ -943,7 +952,18 @@ void HTMLMediaElement::startDelayedLoad()
 {
     ASSERT(m_delayingLoadForPreloadNone);
 
+    // resource fetch algorithm step 3 - continued from loadResource().
+
+    // 5. Wait for an implementation-defined event (e.g. the user requesting that the media element begin playback).
+    // This is assumed to be whatever 'event' ended up calling this method.
     m_delayingLoadForPreloadNone = false;
+    // 6. Set the element's delaying-the-load-event flag back to true (this
+    // delays the load event again, in case it hasn't been fired yet).
+    setShouldDelayLoadEvent(true);
+    // 7. Set the networkState to NETWORK_LOADING.
+    m_networkState = NETWORK_LOADING;
+
+    startProgressEventTimer();
 
     startPlayerLoad();
 }