Ensure incognito TestingProfiles are incognito for their whole lifetime.

chrome/browser/ui/sync/one_click_signin_helper_unittest.cc

Index: chrome/browser/ui/sync/one_click_signin_helper_unittest.cc
diff --git a/chrome/browser/ui/sync/one_click_signin_helper_unittest.cc b/chrome/browser/ui/sync/one_click_signin_helper_unittest.cc
index 13bfd6573afdcd7c1d12bff23aa92c9c7c91ddd0..d9ee9b17679d76d1a31316172983e27bcc5b1d00 100644
--- a/chrome/browser/ui/sync/one_click_signin_helper_unittest.cc
+++ b/chrome/browser/ui/sync/one_click_signin_helper_unittest.cc
@@ -392,10 +392,12 @@ class OneClickSigninHelperIncognitoTest : public OneClickSigninHelperTest {
 
 content::BrowserContext*
 OneClickSigninHelperIncognitoTest::CreateBrowserContext() {
-  // Builds an incognito profile to run this test.
-  TestingProfile::Builder builder;
-  builder.SetIncognito();
-  return builder.Build().release();
+  // Simulate an incognito profile to run this test. RenderViewHostTestHarness
+  // takes ownership of the return value, so it can't be a "proper" incognito
+  // profile, since they are owned by their parent, non-incognito profile.
+  scoped_ptr<TestingProfile> profile = TestingProfile::Builder().Build();
+  profile->ForceIncognito(true);
+  return profile.release();
 }

[tapted, 2014/09/12 07:54:08]

I didn't want to use `ForceIncognito` here, but it was getting complicated
without it. However, I've realised ForceIncognito isn't always to blame for the
problems in http://crbug.com/277296 . Instead it's the GetOriginalProfile()
mismatch while creating the incognito TestingProfile "properly", which this CL
is fixing.

 
 TEST_F(OneClickSigninHelperTest, CanOfferNoContents) {