[cros] Fix MediaURLRequestContext initialization.

content/browser/storage_partition_impl_map.cc

 // Copyright (c) 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "content/browser/storage_partition_impl_map.h"
 
 #include "base/bind.h"
 #include "base/callback.h"
 #include "base/file_path.h"
 #include "base/stl_util.h"
@@ skipping 248 matching lines @@
     // Add content's URLRequestContext's hooks.
     BrowserThread::PostTask(
         BrowserThread::IO, FROM_HERE,
         base::Bind(
             &InitializeURLRequestContext,
             make_scoped_refptr(partition->GetURLRequestContext()),
             make_scoped_refptr(partition->GetAppCacheService()),
             make_scoped_refptr(partition->GetFileSystemContext()),
             make_scoped_refptr(
                 ChromeBlobStorageContext::GetFor(browser_context_))));
-
-    // We do not call InitializeURLRequestContext() for media contexts because,
-    // other than the HTTP cache, the media contexts share the same backing
-    // objects as their associated "normal" request context.  Thus, the previous
-    // call serves to initialize the media request context for this storage
-    // partition as well.
+    BrowserThread::PostTask(
+        BrowserThread::IO, FROM_HERE,
+        base::Bind(
+            &InitializeURLRequestContext,

[Charlie Reis, 2012/09/25 18:29:59]

Can you explain why this fixes the bug?  When Albert replaced this code with the
comment, he also added a comment to InitializeURLRequestContext (above) pointing
out that it would return early because the normal URLRequestContext and
MediaURLRequestContext share the same job factory.  See:
https://codereview.chromium.org/10969017/diff/12009/content/browser/storage_p...

If putting this code back leads to different behavior, then I'm confused about
Albert's comment.  (Does the MediaURLRequestContext actually have a different
job factory that hasn't been initialized yet?)

[Charlie Reis, 2012/09/26 00:47:57]

Nevermind, I looked closer and figured it out.  There's a distinction between
isolated media URLRequestContexts and the default media URLRequestContext. 
Albert's comment here referred to the isolated ones, but I think he forgot that
the default media URLRequestContext has its own job factories.  (See
ProfileImplIOData::LazyInitializeInternal and where it creates
media_request_job_factory_.)

Your CL appears to work, and it will just lead to unnecessary calls of
IntializeURLRequestContext for isolated media URLRequestContexts.  It passes
Albert's regression test, so I don't think it will regress
http://crbug.com/150861.

That said, a better fix is probably to have the default media URLRequestContext
share the main context's job factories, so that we don't have to do this.  I've
verified that that fixes the bug as well, and I'll upload it tomorrow morning.

Given that either CL will fix the bug and we need to merge one to M23, though, I
think this CL is probably the less risky of the two.  Let's land this one, merge
it, and then land mine on M24 as a cleanup.  Sound reasonable?

So, LGTM.

+            make_scoped_refptr(partition->GetMediaURLRequestContext()),
+            make_scoped_refptr(partition->GetAppCacheService()),
+            make_scoped_refptr(partition->GetFileSystemContext()),
+            make_scoped_refptr(
+                ChromeBlobStorageContext::GetFor(browser_context_))));
   }
 }
 
 }  // namespace content