Update MediaKeySession method names to latest EME spec.

Source/modules/encryptedmedia/MediaKeySession.cpp

Index: Source/modules/encryptedmedia/MediaKeySession.cpp
diff --git a/Source/modules/encryptedmedia/MediaKeySession.cpp b/Source/modules/encryptedmedia/MediaKeySession.cpp
index 0760ee356b0780ba0127f132c6ea8d9771a48813..fe2252ad63409169248ab51dfd394fbc991ac9e6 100644
--- a/Source/modules/encryptedmedia/MediaKeySession.cpp
+++ b/Source/modules/encryptedmedia/MediaKeySession.cpp
@@ -48,7 +48,7 @@ MediaKeySession::MediaKeySession(ExecutionContext* context, ContentDecryptionMod
     , m_asyncEventQueue(GenericEventQueue::create(this))
     , m_session(cdm->createSession(this))
     , m_keys(keys)
-    , m_keyRequestTimer(this, &MediaKeySession::keyRequestTimerFired)
+    , m_initializeTimer(this, &MediaKeySession::initializeTimerFired)

[ddorwin, 2014/01/07 02:41:55]

abarth: Is it a requirement that we call these xxxTimerFired? executeXxxTask
would be more meaningful.

     , m_addKeyTimer(this, &MediaKeySession::addKeyTimerFired)
 {
     ScriptWrappable::init(this);
@@ -56,7 +56,7 @@ MediaKeySession::MediaKeySession(ExecutionContext* context, ContentDecryptionMod
 
 MediaKeySession::~MediaKeySession()
 {
-    close();
+    release();
 }
 
 void MediaKeySession::setError(MediaKeyError* error)
@@ -64,12 +64,12 @@ void MediaKeySession::setError(MediaKeyError* error)
     m_error = error;
 }
 
-void MediaKeySession::close()
+void MediaKeySession::release()
 {
     ASSERT(!m_keys == !m_session);
 
     if (m_session)
-        m_session->close();
+        m_session->release();
     m_session.clear();
     m_asyncEventQueue->cancelAllEvents();
 
@@ -83,31 +83,35 @@ String MediaKeySession::sessionId() const
     return m_session->sessionId();
 }
 
-void MediaKeySession::generateKeyRequest(const String& mimeType, Uint8Array* initData)
+void MediaKeySession::initialize(const String& mimeType, Uint8Array* initData)
 {
-    m_pendingKeyRequests.append(PendingKeyRequest(mimeType, initData));
+    m_pendingMimeType = mimeType;
+    m_pendingInitData = initData;
     // FIXME: Eliminate timers. Asynchronicity will be handled in Chromium.

[ddorwin, 2014/01/07 02:41:55]

I added this comment. I wonder if it is correct (see comments in other CL).

In MediaKeys.cpp, I suggest that this method actually be called
schedule...Task... That's fine for these local classes, but it would be a weird
name for a platform interface (e.g. the call at 113). That would be an argument
in favor of doing the asynchronicity in Blink. (See also my other comments about
this at
https://codereview.chromium.org/117323005/diff/70001/Source/modules/encrypted...)

[xhwang, 2014/01/09 01:04:41]

Based on abarth@'s response, we should do this acync'ly in blink.

-    m_keyRequestTimer.startOneShot(0);
+    m_initializeTimer.startOneShot(0);
 }
 
-void MediaKeySession::keyRequestTimerFired(Timer<MediaKeySession>*)
+void MediaKeySession::initializeTimerFired(Timer<MediaKeySession>*)
 {
-    ASSERT(m_pendingKeyRequests.size());
+    ASSERT(!m_pendingMimeType.isEmpty());
     if (!m_session)

[ddorwin, 2014/01/07 02:41:55]

Is this possible?

[xhwang, 2014/01/09 01:04:41]

This is possible when release() is called.

         return;
 
-    while (!m_pendingKeyRequests.isEmpty()) {
-        PendingKeyRequest request = m_pendingKeyRequests.takeFirst();
-
-        // NOTE: Continued from step 5 in MediaKeys::createSession().
-        // The user agent will asynchronously execute the following steps in the task:
-
-        // 1. Let cdm be the cdm loaded in the MediaKeys constructor.
-        // 2. Let destinationURL be null.
-
-        // 3. Use cdm to generate a key request and follow the steps for the first matching condition from the following list:
-        m_session->generateKeyRequest(request.mimeType, *request.initData);
-    }
+    // NOTE: Continued from step 4 in MediaKeys::createSession().
+    // The user agent will asynchronously execute the following steps in the task:
+
+    // 1. Let request be null.

[ddorwin, 2014/01/07 02:41:55]

These comments aren't very helpful here since all the work is done in Chromium.
We should probably just say that the Chromium side is responsible for executing
the [remainder of] task steps.

[xhwang, 2014/01/09 01:04:41]

Added FIXME

+    // 2. Let defaultURL be null.
+    // 3. Wait for the MediaKeys constructor task to complete.

[ddorwin, 2014/01/07 02:41:55]

Should we implement steps 3 and 4 in Blink or Chromium? These seem like
something we could handle in Blink. WDYT? The real question is where we know
that the constructor task has completed and where errors are stored.

(Regardless, I think I'm going to swap 1-2 and 3-4 in the spec.

[xhwang, 2014/01/09 01:04:41]

Added a FIXME.

[ddorwin, 2014/01/25 01:49:36]

FYI, I made this change: https://dvcs.w3.org/hg/html-media/rev/b24748c3d28a

+    // 4. If there is a MediaKeyError stored with the MediaKeys object that occurred because of an error
+    //    during the loading the MediaKeys constructor task then queue a task to fire a simple event named
+    //    error at the MediaKeySession object and abort these steps.
+    // 5. Let cdm be the cdm loaded in the MediaKeys constructor.
+    // 6. Use cdm to execute the following steps:
+    //   1. Process type and initData.
+    //      Note: type should be used to determine how to interpret initData.
+    m_session->initialize(m_pendingMimeType, *m_pendingInitData);
+    m_pendingInitData.clear();
 }
 
 void MediaKeySession::update(Uint8Array* key, ExceptionState& exceptionState)