android: Implement single origin and CORS check for video

android: Implement single origin and CORS check for video

This patch implements hasSingleSecurityOrigin and didPassCORSAccessCheck
for the Android media player. Since we cannot query this information
directly from the native media player, we use a dedicated resource
loader to track redirects and perform the CORS access check. The native
media player is only started after this process has completed.

The new MediaInfoLoader class is based on BufferedResourceLoader. The info
loading request is started in parallel to the media player, and the DOM
ready state is updated only once the info loader has completed and the
player has provided video metadata.

BUG=234710
TEST=https://www.khronos.org/registry/webgl/conformance-suites/1.0.1/conformance/textures/tex-image-and-sub-image-2d-with-video.html

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=205853

[Sami, 2013-06-03 15:53:20]

Hi Min. Here's code to do same-origin and CORS checks for media streams. PTAL.

[qinmin, 2013-06-03 16:55:59]

https://codereview.chromium.org/16327002/diff/1001/webkit/media/android/media...
File webkit/media/android/media_info_loader_android.h (right):

https://codereview.chromium.org/16327002/diff/1001/webkit/media/android/media...
webkit/media/android/media_info_loader_android.h:54: virtual
~MediaInfoLoaderAndroid();
does this needs to be virtual？

https://codereview.chromium.org/16327002/diff/1001/webkit/media/android/webme...
File webkit/media/android/webmediaplayer_android.cc (right):

https://codereview.chromium.org/16327002/diff/1001/webkit/media/android/webme...
webkit/media/android/webmediaplayer_android.cc:111:
pending_media_source_.reset(media_source);
if you split MSE/non-MSE load() call, you don't need this pending_media_source

https://codereview.chromium.org/16327002/diff/1001/webkit/media/android/webme...
webkit/media/android/webmediaplayer_android.cc:113: info_loader_.reset(
I don't think CORS is needed for MSE. 
You might want to split this for MSE and non-MSE case using if(media_source).
Check webmediaplayer_impl.cc.

https://codereview.chromium.org/16327002/diff/1001/webkit/media/android/webme...
webkit/media/android/webmediaplayer_android.cc:118: base::Unretained(this))));
nit: indent

[scherkus (not reviewing), 2013-06-03 16:57:04]

https://codereview.chromium.org/16327002/diff/1001/webkit/media/android/media...
File webkit/media/android/media_info_loader_android.cc (right):

https://codereview.chromium.org/16327002/diff/1001/webkit/media/android/media...
webkit/media/android/media_info_loader_android.cc:126: // Ignored.
so if this was a 100MB media resource do we end up downloading the same file
twice using both Chrome's network stack and Android's media player stack?

[Sami, 2013-06-03 17:12:56]

https://codereview.chromium.org/16327002/diff/1001/webkit/media/android/media...
File webkit/media/android/media_info_loader_android.cc (right):

https://codereview.chromium.org/16327002/diff/1001/webkit/media/android/media...
webkit/media/android/media_info_loader_android.cc:126: // Ignored.
On 2013/06/03 16:57:04, scherkus wrote:
> so if this was a 100MB media resource do we end up downloading the same file
> twice using both Chrome's network stack and Android's media player stack?

No, because as soon as we get a response from the server we cancel the load --
see DidBecomeReady.

https://codereview.chromium.org/16327002/diff/1001/webkit/media/android/media...
File webkit/media/android/media_info_loader_android.h (right):

https://codereview.chromium.org/16327002/diff/1001/webkit/media/android/media...
webkit/media/android/media_info_loader_android.h:54: virtual
~MediaInfoLoaderAndroid();
On 2013/06/03 16:55:59, qinmin wrote:
> does this needs to be virtual？

It's virtual because the base class (WebURLLoaderClient) has a virtual
destructor. I'm just following the convention of marking everything that's
virtual explicitly so.

https://codereview.chromium.org/16327002/diff/1001/webkit/media/android/webme...
File webkit/media/android/webmediaplayer_android.cc (right):

https://codereview.chromium.org/16327002/diff/1001/webkit/media/android/webme...
webkit/media/android/webmediaplayer_android.cc:111:
pending_media_source_.reset(media_source);
On 2013/06/03 16:55:59, qinmin wrote:
> if you split MSE/non-MSE load() call, you don't need this pending_media_source

Sorry, I don't know what MSE stands for :) Do you mean that whenever we have a
media source we don't need to care about CORS/single-origin? I've now change
this to work like that.

https://codereview.chromium.org/16327002/diff/1001/webkit/media/android/webme...
webkit/media/android/webmediaplayer_android.cc:113: info_loader_.reset(
On 2013/06/03 16:55:59, qinmin wrote:
> I don't think CORS is needed for MSE. 
> You might want to split this for MSE and non-MSE case using if(media_source).
> Check webmediaplayer_impl.cc.

Done.

https://codereview.chromium.org/16327002/diff/1001/webkit/media/android/webme...
webkit/media/android/webmediaplayer_android.cc:118: base::Unretained(this))));
On 2013/06/03 16:55:59, qinmin wrote:
> nit: indent

Done.

[scherkus (not reviewing), 2013-06-03 17:37:39]

https://codereview.chromium.org/16327002/diff/1001/webkit/media/android/media...
File webkit/media/android/media_info_loader_android.cc (right):

https://codereview.chromium.org/16327002/diff/1001/webkit/media/android/media...
webkit/media/android/media_info_loader_android.cc:126: // Ignored.
On 2013/06/03 17:12:56, Sami wrote:
> On 2013/06/03 16:57:04, scherkus wrote:
> > so if this was a 100MB media resource do we end up downloading the same file
> > twice using both Chrome's network stack and Android's media player stack?
> 
> No, because as soon as we get a response from the server we cancel the load --
> see DidBecomeReady.

OK .. but this is still an additional HTTP roundtrip that gets cancelled prior
to doing the real load, which is pretty unfortunate.

Do you have any #s on how this will affect load times over mobile networks?

Have you reached out to the Android team to see whether they can provide this
information in a future version of the API?

[qinmin, 2013-06-04 02:43:27]

lgtm % nits

https://codereview.chromium.org/16327002/diff/2008/webkit/renderer/media/andr...
File webkit/renderer/media/android/media_info_loader_android.cc (right):

https://codereview.chromium.org/16327002/diff/2008/webkit/renderer/media/andr...
webkit/renderer/media/android/media_info_loader_android.cc:37:
active_loader_.reset();
nit: is there any benefit of doing this? scoped_ptr is going away anyway

[Sami, 2013-06-04 11:08:22]

>
https://codereview.chromium.org/16327002/diff/2008/webkit/renderer/media/andr...
> webkit/renderer/media/android/media_info_loader_android.cc:37:
> active_loader_.reset();
> nit: is there any benefit of doing this? scoped_ptr is going away anyway

Ah, you're right -- this used to be a Stop() method that I turned into a
destructor and failed to notice it doesn't actually need to do anything.

> OK .. but this is still an additional HTTP roundtrip that gets cancelled prior
> to doing the real load, which is pretty unfortunate.
>
> Do you have any #s on how this will affect load times over mobile networks?

You're absolutely right. Unfortunately I don't see any other way of implementing
this given the way Android currently works.

I tried to do some measurements on how long it takes to get the first frame out
of the video element on HSDPA. I don't know if it was my operator's shenanigans
or what but the video element refused to play with or without this patch. On
WiFi I didn't see a measurable difference -- the delay was almost exactly 2
seconds on a Nexus 4.

> Have you reached out to the Android team to see whether they can provide this
> information in a future version of the API?

Great idea. I've opened b/9271857 to track this.

[Sami, 2013-06-04 11:12:09]

piman@, mind checking content/content_tests.gypi? Thanks.

[Ken Russell (switch to Gerrit), 2013-06-05 18:33:50]

This looks excellent; one question.

https://codereview.chromium.org/16327002/diff/12001/webkit/renderer/media/and...
File webkit/renderer/media/android/webmediaplayer_android.cc (right):

https://codereview.chromium.org/16327002/diff/12001/webkit/renderer/media/and...
webkit/renderer/media/android/webmediaplayer_android.cc:369: return false;
Should this return true? WebMediaPlayerImpl::hasSingleSecurityOrigin returns
true in the fall-through case. What case does that handle? getUserMedia with a
webcam's input?

[Sami, 2013-06-06 12:29:48]

Thanks Ken. scherkus@, piman@, any thouhts?

https://codereview.chromium.org/16327002/diff/12001/webkit/renderer/media/and...
File webkit/renderer/media/android/webmediaplayer_android.cc (right):

https://codereview.chromium.org/16327002/diff/12001/webkit/renderer/media/and...
webkit/renderer/media/android/webmediaplayer_android.cc:369: return false;
On 2013/06/05 18:33:50, kbr wrote:
> Should this return true? WebMediaPlayerImpl::hasSingleSecurityOrigin returns
> true in the fall-through case. What case does that handle? getUserMedia with a
> webcam's input?

This path is reached when we're playing from a media source/stream. I tested
that the getUserMedia webcam case goes through webmediaplayer_ms.cc so I'm not
exactly sure when we end up here. I'll change this to be consistent with
WebMediaPlayerImpl.

[piman, 2013-06-06 16:39:42]

LGTM for the gyp change.

[Sami, 2013-06-06 16:55:46]

Added some owners for webkit/renderer/media/webkit_media.gypi. PTAL.

[Sami, 2013-06-10 09:32:15]

Friendy ping to webkit/renderer/media owners, thanks!

[Ken Russell (switch to Gerrit), 2013-06-10 17:40:22]

+vrk for OWNERS

[vrk (LEFT CHROMIUM), 2013-06-10 18:32:51]

OWNERS lgtm

[commit-bot: I haz the power, 2013-06-10 18:35:20]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/[email protected]/16327002/18001

[commit-bot: I haz the power, 2013-06-10 18:35:22]

Failed to apply patch for
webkit/renderer/media/android/webmediaplayer_android.cc:
While running patch -p1 --forward --force --no-backup-if-mismatch;
  patching file webkit/renderer/media/android/webmediaplayer_android.cc
  Hunk #1 succeeded at 150 (offset 2 lines).
  Hunk #2 FAILED at 183.
  Hunk #3 succeeded at 372 (offset -32 lines).
  1 out of 3 hunks FAILED -- saving rejects to file
webkit/renderer/media/android/webmediaplayer_android.cc.rej

Patch:       webkit/renderer/media/android/webmediaplayer_android.cc
Index: webkit/renderer/media/android/webmediaplayer_android.cc
diff --git a/webkit/renderer/media/android/webmediaplayer_android.cc
b/webkit/renderer/media/android/webmediaplayer_android.cc
index
17017dbbb4c8ecc8cb26acfbb4dded33712d6f97..91c142df9f724b711563cbd403f491205a1a845b
100644
--- a/webkit/renderer/media/android/webmediaplayer_android.cc
+++ b/webkit/renderer/media/android/webmediaplayer_android.cc
@@ -148,11 +148,9 @@ void WebMediaPlayerAndroid::load(const WebURL& url,
CORSMode cors_mode) {
 void WebMediaPlayerAndroid::load(const WebURL& url,
                                  WebMediaSource* media_source,
                                  CORSMode cors_mode) {
-  if (cors_mode != CORSModeUnspecified)
-    NOTIMPLEMENTED() << "No CORS support";
-
   MediaPlayerAndroid::SourceType source_type =
       MediaPlayerAndroid::SOURCE_TYPE_URL;
+  url_ = url;
 
   if (media_source)
     source_type = MediaPlayerAndroid::SOURCE_TYPE_MSE;
@@ -185,28 +183,43 @@ void WebMediaPlayerAndroid::load(const WebURL& url,
         audio_renderer_->Start();
     }
 #endif
+    InitializeMediaPlayer(source_type);
+  } else {
+    info_loader_.reset(
+        new MediaInfoLoaderAndroid(
+            url_,
+            cors_mode,
+            base::Bind(&WebMediaPlayerAndroid::DidLoadMediaInfo,
+                       base::Unretained(this))));
+    info_loader_->Start(frame_);
+  }
+  UpdateNetworkState(WebMediaPlayer::NetworkStateLoading);
+  UpdateReadyState(WebMediaPlayer::ReadyStateHaveNothing);
+}
+
+void WebMediaPlayerAndroid::DidLoadMediaInfo(
+    MediaInfoLoaderAndroid::Status status) {
+  DCHECK(!media_source_delegate_);
+  if (status == MediaInfoLoaderAndroid::kFailed) {
+    info_loader_.reset();
+    return;
   }
 
-  InitializeMediaPlayer(url, source_type);
+  InitializeMediaPlayer(MediaPlayerAndroid::SOURCE_TYPE_URL);
 }
 
 void WebMediaPlayerAndroid::InitializeMediaPlayer(
-    const WebURL& url,
     MediaPlayerAndroid::SourceType source_type) {
-  url_ = url;
   GURL first_party_url = frame_->document().firstPartyForCookies();
   if (proxy_) {
-    proxy_->Initialize(player_id_, url, source_type, first_party_url);
+    proxy_->Initialize(player_id_, url_, source_type, first_party_url);
     if (manager_->IsInFullscreen(frame_))
       proxy_->EnterFullscreen(player_id_);
   }
-
-  UpdateNetworkState(WebMediaPlayer::NetworkStateLoading);
-  UpdateReadyState(WebMediaPlayer::ReadyStateHaveNothing);
 }
 
 void WebMediaPlayerAndroid::cancelLoad() {
-  NOTIMPLEMENTED();
+  info_loader_.reset();
 }
 
 void WebMediaPlayerAndroid::play() {
@@ -406,14 +419,14 @@ bool
WebMediaPlayerAndroid::copyVideoTextureToPlatformTexture(
 }
 
 bool WebMediaPlayerAndroid::hasSingleSecurityOrigin() const {
-  // TODO(qinmin): fix this for urls that are not file.
-  // https://code.google.com/p/chromium/issues/detail?id=234710
-  if (url_.SchemeIsFile())
-    return true;
-  return false;
+  if (info_loader_)
+    return info_loader_->HasSingleOrigin();
+  return true;
 }
 
 bool WebMediaPlayerAndroid::didPassCORSAccessCheck() const {
+  if (info_loader_)
+    return info_loader_->DidPassCORSAccessCheck();
   return false;
 }

[vrk (LEFT CHROMIUM), 2013-06-10 18:54:05]

Gah I'm so sorry; I didn't realize that scherkus had unanswered concerns earlier
in the thread. Since I haven't been working in this space lately, please wait to
commit until scherkus's OK - I'll corner him today to get a response! :)

[vrk (LEFT CHROMIUM), 2013-06-10 18:55:14]

On 2013/06/10 18:54:05, Victoria Kirst wrote:
> Gah I'm so sorry; I didn't realize that scherkus had unanswered concerns
earlier
> in the thread.

That is, not unanswered, but unacked. Would like him to ack before OKing!

[acolwell GONE FROM CHROMIUM, 2013-06-10 19:17:32]

https://codereview.chromium.org/16327002/diff/18001/webkit/renderer/media/and...
File webkit/renderer/media/android/media_info_loader_android.cc (right):

https://codereview.chromium.org/16327002/diff/18001/webkit/renderer/media/and...
webkit/renderer/media/android/media_info_loader_android.cc:112: } else {
nit: drop else and early return above.

https://codereview.chromium.org/16327002/diff/18001/webkit/renderer/media/and...
File webkit/renderer/media/android/media_info_loader_android_unittest.cc
(right):

https://codereview.chromium.org/16327002/diff/18001/webkit/renderer/media/and...
webkit/renderer/media/android/media_info_loader_android_unittest.cc:77: GURL
redirectUrl(url);
nit: s/redirectUrl/redirect_url/

https://codereview.chromium.org/16327002/diff/18001/webkit/renderer/media/and...
webkit/renderer/media/android/media_info_loader_android_unittest.cc:78:
WebKit::WebURLRequest newRequest(redirectUrl);
nit: s/newRequest/new_request/

https://codereview.chromium.org/16327002/diff/18001/webkit/renderer/media/and...
webkit/renderer/media/android/media_info_loader_android_unittest.cc:79:
WebKit::WebURLResponse redirectResponse(gurl_);
nit: s/redirectResponse/redirect_response/

https://codereview.chromium.org/16327002/diff/18001/webkit/renderer/media/and...
webkit/renderer/media/android/media_info_loader_android_unittest.cc:142:
Initialize(kHttpUrl, WebKit::WebMediaPlayer::CORSModeUnspecified);
nit: split these out into seperate tests so that they can fail separately.

https://codereview.chromium.org/16327002/diff/18001/webkit/renderer/media/and...
File webkit/renderer/media/android/webmediaplayer_android.cc (right):

https://codereview.chromium.org/16327002/diff/18001/webkit/renderer/media/and...
webkit/renderer/media/android/webmediaplayer_android.cc:204:
info_loader_.reset();
I think you need to add something like
UpdateNetworkState(WebMediaPlayer::NetworkStateNetworkError) here so that the
HTMLMediaElement can correctly report the error state.

https://codereview.chromium.org/16327002/diff/18001/webkit/renderer/media/and...
webkit/renderer/media/android/webmediaplayer_android.cc:221: void
WebMediaPlayerAndroid::cancelLoad() {
nit: Please remove. This method is never called.

https://codereview.chromium.org/16327002/diff/33001/webkit/renderer/media/and...
File webkit/renderer/media/android/media_info_loader_android.h (right):

https://codereview.chromium.org/16327002/diff/33001/webkit/renderer/media/and...
webkit/renderer/media/android/media_info_loader_android.h:28: class
MediaInfoLoaderAndroid : private WebKit::WebURLLoaderClient {
nit: None of this code looks Android specific. Consider moving it up a directory
and dropping the Android from the name.

[scherkus (not reviewing), 2013-06-11 02:19:34]

I'm not comfortable landing this patch w/o any way of knowing what the impact
will be on real users.

Can we get UMA stats in place for measuring the time it takes to complete the
CORS check in the real world?

Also is it possible to only do this check based on the value of cors_mode? I'd
be nice to not penalize the startup latency for content that doesn't use CORS.

[Sami, 2013-06-11 13:51:24]

https://codereview.chromium.org/16327002/diff/18001/webkit/renderer/media/and...
File webkit/renderer/media/android/media_info_loader_android.cc (right):

https://codereview.chromium.org/16327002/diff/18001/webkit/renderer/media/and...
webkit/renderer/media/android/media_info_loader_android.cc:112: } else {
On 2013/06/10 19:17:32, acolwell wrote:
> nit: drop else and early return above.

Done.

https://codereview.chromium.org/16327002/diff/18001/webkit/renderer/media/and...
File webkit/renderer/media/android/media_info_loader_android_unittest.cc
(right):

https://codereview.chromium.org/16327002/diff/18001/webkit/renderer/media/and...
webkit/renderer/media/android/media_info_loader_android_unittest.cc:77: GURL
redirectUrl(url);
On 2013/06/10 19:17:32, acolwell wrote:
> nit: s/redirectUrl/redirect_url/

Done.

https://codereview.chromium.org/16327002/diff/18001/webkit/renderer/media/and...
webkit/renderer/media/android/media_info_loader_android_unittest.cc:78:
WebKit::WebURLRequest newRequest(redirectUrl);
On 2013/06/10 19:17:32, acolwell wrote:
> nit: s/newRequest/new_request/

Done.

https://codereview.chromium.org/16327002/diff/18001/webkit/renderer/media/and...
webkit/renderer/media/android/media_info_loader_android_unittest.cc:79:
WebKit::WebURLResponse redirectResponse(gurl_);
On 2013/06/10 19:17:32, acolwell wrote:
> nit: s/redirectResponse/redirect_response/

Done.

https://codereview.chromium.org/16327002/diff/18001/webkit/renderer/media/and...
webkit/renderer/media/android/media_info_loader_android_unittest.cc:142:
Initialize(kHttpUrl, WebKit::WebMediaPlayer::CORSModeUnspecified);
On 2013/06/10 19:17:32, acolwell wrote:
> nit: split these out into seperate tests so that they can fail separately.

Good idea, done.

https://codereview.chromium.org/16327002/diff/18001/webkit/renderer/media/and...
File webkit/renderer/media/android/webmediaplayer_android.cc (right):

https://codereview.chromium.org/16327002/diff/18001/webkit/renderer/media/and...
webkit/renderer/media/android/webmediaplayer_android.cc:204:
info_loader_.reset();
On 2013/06/10 19:17:32, acolwell wrote:
> I think you need to add something like
> UpdateNetworkState(WebMediaPlayer::NetworkStateNetworkError) here so that the
> HTMLMediaElement can correctly report the error state.

Well spotted, thanks. Done.

https://codereview.chromium.org/16327002/diff/18001/webkit/renderer/media/and...
webkit/renderer/media/android/webmediaplayer_android.cc:221: void
WebMediaPlayerAndroid::cancelLoad() {
On 2013/06/10 19:17:32, acolwell wrote:
> nit: Please remove. This method is never called.

Done.

https://codereview.chromium.org/16327002/diff/33001/webkit/renderer/media/and...
File webkit/renderer/media/android/media_info_loader_android.h (right):

https://codereview.chromium.org/16327002/diff/33001/webkit/renderer/media/and...
webkit/renderer/media/android/media_info_loader_android.h:28: class
MediaInfoLoaderAndroid : private WebKit::WebURLLoaderClient {
On 2013/06/10 19:17:33, acolwell wrote:
> nit: None of this code looks Android specific. Consider moving it up a
directory
> and dropping the Android from the name.

That's true. I'll move it to the parent directory.

[Sami, 2013-06-11 14:14:01]

On 2013/06/11 02:19:34, scherkus wrote:
> I'm not comfortable landing this patch w/o any way of knowing what the impact
> will be on real users.

That's a fair point. I retried my experiment from last week and was able to get
the video to play this time. With the server located across the Atlantic,
loading the media info takes about 450 ms on HSDPA and 200 ms on WiFi. To give
some context, it takes about 9 seconds in total for the first video frame to
appear on HSDPA -- and this was with a very simple synthetic test video. I think
the additional delay corresponds to 2 packet round trips.

> Can we get UMA stats in place for measuring the time it takes to complete the
> CORS check in the real world?

Good idea. I've added a statistic for the info loading delay.

> Also is it possible to only do this check based on the value of cors_mode? I'd
> be nice to not penalize the startup latency for content that doesn't use CORS.

Unfortunately we still have to track the redirects regardless of CORS.

[Sami, 2013-06-11 17:29:26]

With the hopes of addressing the extra http request delay concerns, I've
uploaded a patch that runs the media info fetch parallel to starting the
decoder.

Min, could you take a look at how I'm delaying the UpdateReadyState() call here
and confirm it makes sense?

[qinmin, 2013-06-11 17:54:20]

On 2013/06/11 17:29:26, Sami wrote:
> With the hopes of addressing the extra http request delay concerns, I've
> uploaded a patch that runs the media info fetch parallel to starting the
> decoder.
> 
> Min, could you take a look at how I'm delaying the UpdateReadyState() call
here
> and confirm it makes sense?

The UpdateReadyState() looks ok to me

[Ken Russell (switch to Gerrit), 2013-06-11 20:11:45]

LGTM again assuming it still passes the WebGL video conformance tests.

[scherkus (not reviewing), 2013-06-12 01:37:58]

don't forget to update the CL description based on new implementation

lgtm w/ nits

https://codereview.chromium.org/16327002/diff/49001/webkit/renderer/media/and...
File webkit/renderer/media/android/webmediaplayer_android.cc (right):

https://codereview.chromium.org/16327002/diff/49001/webkit/renderer/media/and...
webkit/renderer/media/android/webmediaplayer_android.cc:405: return true;
do we need to worry about the case where info_loader_ failed (and is deleted)
and this now returns true?

https://codereview.chromium.org/16327002/diff/49001/webkit/renderer/media/med...
File webkit/renderer/media/media_info_loader.cc (right):

https://codereview.chromium.org/16327002/diff/49001/webkit/renderer/media/med...
webkit/renderer/media/media_info_loader.cc:80: 
nit: remove extra blank line

https://codereview.chromium.org/16327002/diff/49001/webkit/renderer/media/med...
webkit/renderer/media/media_info_loader.cc:179:
UMA_HISTOGRAM_TIMES("MediaInfoLoader.ReadyDelayTime",
don't forget the change in src/tools/metrics/histograms/histograms.xml

[Sami, 2013-06-12 13:59:30]

Thanks all, all nits addressed (and the WebGL test still passes).

https://codereview.chromium.org/16327002/diff/49001/webkit/renderer/media/and...
File webkit/renderer/media/android/webmediaplayer_android.cc (right):

https://codereview.chromium.org/16327002/diff/49001/webkit/renderer/media/and...
webkit/renderer/media/android/webmediaplayer_android.cc:405: return true;
On 2013/06/12 01:37:58, scherkus wrote:
> do we need to worry about the case where info_loader_ failed (and is deleted)
> and this now returns true?

Yes, I'll add a check for that.

https://codereview.chromium.org/16327002/diff/49001/webkit/renderer/media/med...
File webkit/renderer/media/media_info_loader.cc (right):

https://codereview.chromium.org/16327002/diff/49001/webkit/renderer/media/med...
webkit/renderer/media/media_info_loader.cc:80: 
On 2013/06/12 01:37:58, scherkus wrote:
> nit: remove extra blank line

Done.

https://codereview.chromium.org/16327002/diff/49001/webkit/renderer/media/med...
webkit/renderer/media/media_info_loader.cc:179:
UMA_HISTOGRAM_TIMES("MediaInfoLoader.ReadyDelayTime",
On 2013/06/12 01:37:58, scherkus wrote:
> don't forget the change in src/tools/metrics/histograms/histograms.xml

Thanks, I wasn't aware of that file.

[Sami, 2013-06-12 14:01:14]

Adding +asvitkine@ for tools/metrics/histograms/histograms.xml, thanks!

[Alexei Svitkine (slow), 2013-06-12 14:46:22]

histograms.xml lgtm

[commit-bot: I haz the power, 2013-06-12 14:54:15]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/[email protected]/16327002/58001

[commit-bot: I haz the power, 2013-06-12 17:37:09]

Change committed as 205853