Domain Reliability: Remove browsing data when requested.

Domain Reliability: Remove browsing data when requested.

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

[Deprecated (see juliatuttle), 2014-04-24 15:14:43]

PTAL.

[Ryan Sleevi, 2014-04-24 15:17:22]

You need a browsing_data owner for the bulk of this, so throwing it at Mike.

[Mike West, 2014-04-24 16:09:35]

Looks reasonable in a quick skim, but I won't be able to take a deeper look
until tomorrow morning (GMT+2).

[Deprecated (see juliatuttle), 2014-04-24 17:29:26]

On 2014/04/24 16:09:35, Mike West wrote:
> Looks reasonable in a quick skim, but I won't be able to take a deeper look
> until tomorrow morning (GMT+2).

Thanks. In particular, I'd be curious about suggestions on testing the new logic
I've added. I paralleled the logic for ClearNetworkingHistorySince, but it
doesn't have tests either.

[Mike West, 2014-04-25 07:17:30]

On 2014/04/24 17:29:26, ttuttle wrote:
> On 2014/04/24 16:09:35, Mike West wrote:
> > Looks reasonable in a quick skim, but I won't be able to take a deeper look
> > until tomorrow morning (GMT+2).
> 
> Thanks. In particular, I'd be curious about suggestions on testing the new
logic
> I've added. I paralleled the logic for ClearNetworkingHistorySince, but it
> doesn't have tests either.

The change looks good with the single nit I noted.

With regard to testing, I'd suggest two things:

1. Put some unit tests in the component that verify that the clear functions
you've created do the right thing. Create some data, make sure that it's gone
when the functions are called.

2. Verify that the methods you care about are called when clearing browsing data
with an appropriate mask. You can either do this via a mock, (as in the
ContentProtectionPlatformKeysRemoval test), or by adding a new tester class that
pipes through access to your components so you can directly verify that things
were deleted. Either way is fine.

Did you have specific questions about how you'd go about doing that? I hope that
the other testing classes in that file are reasonable examples for you, but I'm
happy to spend some time (on VC, if you like?) to talk about them in more
detail.

https://codereview.chromium.org/238863005/diff/60001/chrome/browser/browsing_...
File chrome/browser/browsing_data/browsing_data_remover_unittest.cc (right):

https://codereview.chromium.org/238863005/diff/60001/chrome/browser/browsing_...
chrome/browser/browsing_data/browsing_data_remover_unittest.cc:1608: //
TODO(ttuttle): Test ClearNetworkingHistorySince, or find someone else to.
Let's find someone else; that shouldn't be your job (unless you want it to be!).
Please file a bug and I'll try to track someone down.

https://codereview.chromium.org/238863005/diff/60001/chrome/browser/profiles/...
File chrome/browser/profiles/profile_impl_io_data.h (right):

https://codereview.chromium.org/238863005/diff/60001/chrome/browser/profiles/...
chrome/browser/profiles/profile_impl_io_data.h:102: void
ClearDomainReliabilityMonitor(bool clear_contexts,
Nit: Can you change this to an enum? Magical bools are confusing, and no one
reads comments. :)

[Deprecated (see juliatuttle), 2014-05-01 21:53:25]

I've got unittests for the component itself.

I think the right way to mock things would be to mock the Profile itself, create
a BrowsingDataRemover that calls ClearDomainReliabilityMonitor on the mock
Profile, and assume the plumbing between Profile and PRofileImplIOData is solid.

Does that sound reasonable?

https://codereview.chromium.org/238863005/diff/60001/chrome/browser/browsing_...
File chrome/browser/browsing_data/browsing_data_remover_unittest.cc (right):

https://codereview.chromium.org/238863005/diff/60001/chrome/browser/browsing_...
chrome/browser/browsing_data/browsing_data_remover_unittest.cc:1608: //
TODO(ttuttle): Test ClearNetworkingHistorySince, or find someone else to.
On 2014/04/25 07:17:31, Mike West (OOO until the 5th) wrote:
> Let's find someone else; that shouldn't be your job (unless you want it to
be!).
> Please file a bug and I'll try to track someone down.

Done: http://crbug.com/369251

https://codereview.chromium.org/238863005/diff/60001/chrome/browser/profiles/...
File chrome/browser/profiles/profile_impl_io_data.h (right):

https://codereview.chromium.org/238863005/diff/60001/chrome/browser/profiles/...
chrome/browser/profiles/profile_impl_io_data.h:102: void
ClearDomainReliabilityMonitor(bool clear_contexts,
On 2014/04/25 07:17:31, Mike West (OOO until the 5th) wrote:
> Nit: Can you change this to an enum? Magical bools are confusing, and no one
> reads comments. :)

Done. (That was a *pain*.)

[Mike West, 2014-05-05 06:54:24]

On 2014/05/01 21:53:25, ttuttle wrote:
> I've got unittests for the component itself.
> 
> I think the right way to mock things would be to mock the Profile itself,
create
> a BrowsingDataRemover that calls ClearDomainReliabilityMonitor on the mock
> Profile, and assume the plumbing between Profile and PRofileImplIOData is
solid.
> 
> Does that sound reasonable?

Yup, that sounds reasonable. I don't think there's any need for an end-to-end
test if you have unit tests for the various components, and the linkage between
them. Verifying that ClearDomainReliabilityMonitor is called with the right
arguments should be enough.

>
https://codereview.chromium.org/238863005/diff/60001/chrome/browser/profiles/...
> File chrome/browser/profiles/profile_impl_io_data.h (right):
> 
>
https://codereview.chromium.org/238863005/diff/60001/chrome/browser/profiles/...
> chrome/browser/profiles/profile_impl_io_data.h:102: void
> ClearDomainReliabilityMonitor(bool clear_contexts,
> On 2014/04/25 07:17:31, Mike West (OOO until the 5th) wrote:
> > Nit: Can you change this to an enum? Magical bools are confusing, and no one
> > reads comments. :)
> 
> Done. (That was a *pain*.)

Sorry for the pain, but thank you! I think the code ends up being more
comprehensible.

[Deprecated (see juliatuttle), 2014-05-05 17:49:57]

On 2014/05/05 06:54:24, Mike West (OOO until the 5th) wrote:
> On 2014/05/01 21:53:25, ttuttle wrote:
> > I've got unittests for the component itself.
> > 
> > I think the right way to mock things would be to mock the Profile itself,
> create
> > a BrowsingDataRemover that calls ClearDomainReliabilityMonitor on the mock
> > Profile, and assume the plumbing between Profile and PRofileImplIOData is
> solid.
> > 
> > Does that sound reasonable?
> 
> Yup, that sounds reasonable. I don't think there's any need for an end-to-end
> test if you have unit tests for the various components, and the linkage
between
> them. Verifying that ClearDomainReliabilityMonitor is called with the right
> arguments should be enough.

Hmm.  It doesn't look like anything else in BrowsingDataRemoverTest mocks
Profile.

How bad would it be to add a method to TestingProfile that lets me check whether
the domain reliability stuff has been cleared?

> Sorry for the pain, but thank you! I think the code ends up being more
> comprehensible.

No worries; it was just a lot of re-plumbing and #including things.

[Mike West, 2014-05-07 13:41:00]

Sorry for the delay on this. I lost track of it; I'll review whatever you come
up with first thing in the morning, I promise.

On 2014/05/05 17:49:57, ttuttle wrote:
> How bad would it be to add a method to TestingProfile that lets me check
whether
> the domain reliability stuff has been cleared?

I think that'd be fine. If you don't want to add it to TestingProfile proper,
you could certainly extend ProfileMock in order to verify that
'ClearDomainReliabilityMonitor' is called with the correct argument. You're
verifying the rest with the domain_reliability unit tests.

+sky for his opinion as a chrome/test OWNER. :)

[sky, 2014-05-07 16:32:58]

On 2014/05/05 17:49:57, ttuttle wrote:
> On 2014/05/05 06:54:24, Mike West (OOO until the 5th) wrote:
> > On 2014/05/01 21:53:25, ttuttle wrote:
> > > I've got unittests for the component itself.
> > > 
> > > I think the right way to mock things would be to mock the Profile itself,
> > create
> > > a BrowsingDataRemover that calls ClearDomainReliabilityMonitor on the mock
> > > Profile, and assume the plumbing between Profile and PRofileImplIOData is
> > solid.
> > > 
> > > Does that sound reasonable?
> > 
> > Yup, that sounds reasonable. I don't think there's any need for an
end-to-end
> > test if you have unit tests for the various components, and the linkage
> between
> > them. Verifying that ClearDomainReliabilityMonitor is called with the right
> > arguments should be enough.
> 
> Hmm.  It doesn't look like anything else in BrowsingDataRemoverTest mocks
> Profile.
> 
> How bad would it be to add a method to TestingProfile that lets me check
whether
> the domain reliability stuff has been cleared?

Why do you need to add it to TestingProfile and not your test? Is it because
your test doesn't have access to state in TestingProfile?

> 
> > Sorry for the pain, but thank you! I think the code ends up being more
> > comprehensible.
> 
> No worries; it was just a lot of re-plumbing and #including things.

[Deprecated (see juliatuttle), 2014-05-07 16:58:35]

On 2014/05/07 16:32:58, sky wrote:
> On 2014/05/05 17:49:57, ttuttle wrote:
> > How bad would it be to add a method to TestingProfile that lets me check
> whether
> > the domain reliability stuff has been cleared?
> 
> Why do you need to add it to TestingProfile and not your test? Is it because
> your test doesn't have access to state in TestingProfile?

The state I'm looking to test does not actually exist in TestingProfile.

I suppose I could give it a DomainReliabilityMonitor (just like the real
Profile), but it wouldn't end up actually receiving any information that could
be cleared.

[sky, 2014-05-07 19:43:53]

Maybe I'm missing something, but it seems like this state should not
be in TestingProfile, but instead your test.

  -Scott

On Wed, May 7, 2014 at 9:58 AM,  <ttuttle@chromium.org> wrote:
> On 2014/05/07 16:32:58, sky wrote:
>>
>> On 2014/05/05 17:49:57, ttuttle wrote:
>> > How bad would it be to add a method to TestingProfile that lets me check
>> whether
>> > the domain reliability stuff has been cleared?
>
>
>> Why do you need to add it to TestingProfile and not your test? Is it
>> because
>> your test doesn't have access to state in TestingProfile?
>
>
> The state I'm looking to test does not actually exist in TestingProfile.
>
> I suppose I could give it a DomainReliabilityMonitor (just like the real
> Profile), but it wouldn't end up actually receiving any information that
> could
> be cleared.
>
> https://codereview.chromium.org/238863005/

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[Deprecated (see juliatuttle), 2014-05-07 21:50:41]

On 2014/05/07 19:43:53, sky wrote:
> Maybe I'm missing something, but it seems like this state should not
> be in TestingProfile, but instead your test.

Okay, I've subclassed TestingProfile to make it work with
DomainReliabilityMonitor, then added getters (_for_testing) to
DomainReliabilityMonitor to inspect that state.

[Mike West, 2014-05-08 11:00:39]

c/b/browsing_data LGTM with two small comments. Thanks.

https://codereview.chromium.org/238863005/diff/160001/chrome/browser/browsing...
File chrome/browser/browsing_data/browsing_data_remover_unittest.cc (right):

https://codereview.chromium.org/238863005/diff/160001/chrome/browser/browsing...
chrome/browser/browsing_data/browsing_data_remover_unittest.cc:1659:
BrowsingDataRemover::REMOVE_COOKIES, false);
Could you add a test with the protected origins flag set to true?

https://codereview.chromium.org/238863005/diff/160001/components/domain_relia...
File components/domain_reliability/monitor.cc (right):

https://codereview.chromium.org/238863005/diff/160001/components/domain_relia...
components/domain_reliability/monitor.cc:153: default:
Nit: If you replace this with 'case MAX_CLEAR_MODE:', you'll automagically get a
compilation error if you add another value to the enum in the future.

[Deprecated (see juliatuttle), 2014-05-08 15:47:38]

https://codereview.chromium.org/238863005/diff/160001/chrome/browser/browsing...
File chrome/browser/browsing_data/browsing_data_remover_unittest.cc (right):

https://codereview.chromium.org/238863005/diff/160001/chrome/browser/browsing...
chrome/browser/browsing_data/browsing_data_remover_unittest.cc:1659:
BrowsingDataRemover::REMOVE_COOKIES, false);
On 2014/05/08 11:00:40, Mike West wrote:
> Could you add a test with the protected origins flag set to true?

Done.

https://codereview.chromium.org/238863005/diff/160001/components/domain_relia...
File components/domain_reliability/monitor.cc (right):

https://codereview.chromium.org/238863005/diff/160001/components/domain_relia...
components/domain_reliability/monitor.cc:153: default:
On 2014/05/08 11:00:40, Mike West wrote:
> Nit: If you replace this with 'case MAX_CLEAR_MODE:', you'll automagically get
a
> compilation error if you add another value to the enum in the future.

Done.

[Deprecated (see juliatuttle), 2014-05-09 02:26:42]

The CQ bit was checked by ttuttle@chromium.org

[commit-bot: I haz the power, 2014-05-09 02:27:35]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/ttuttle@chromium.org/238863005/180001

[commit-bot: I haz the power, 2014-05-09 06:41:37]

FYI, CQ is re-trying this CL (attempt #1).
Please consider checking whether the failures are real,
and report flakes to chrome-troopers@google.com.
The failing builders are:
  android_dbg_triggered_tests on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/android_dbg_triggered...)
  chromium_presubmit on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/chromium_presubmit/bu...)
  linux_chromium_chromeos_rel on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/linux_chromium_chrome...)
  linux_chromium_rel on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/linux_chromium_rel/bu...)
  mac_chromium_rel on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/mac_chromium_rel/buil...)
  win_chromium_rel on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/win_chromium_rel/buil...)
  win_chromium_x64_rel on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/win_chromium_x64_rel/...)

[commit-bot: I haz the power, 2014-05-09 06:49:24]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-05-09 06:49:25]

Try jobs failed on following builders:
  chromium_presubmit on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/chromium_presubmit/bu...)

[sky, 2014-05-09 17:03:57]

As mentioned you should get a more local owner for profiles. The other random
chrome changes LGTM

[Deprecated (see juliatuttle), 2014-05-09 17:11:57]

rlp: PTAL at chrome/browser/profiles/*
davidben: PTAL at components/doma_reliability*

[mmenke, 2014-05-09 18:06:08]

profiles/ LGTM

[Deprecated (see juliatuttle), 2014-05-09 18:09:40]

The CQ bit was checked by ttuttle@chromium.org

[commit-bot: I haz the power, 2014-05-09 18:13:40]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/ttuttle@chromium.org/238863005/220001

[commit-bot: I haz the power, 2014-05-09 20:07:33]

FYI, CQ is re-trying this CL (attempt #1).
Please consider checking whether the failures are real,
and report flakes to chrome-troopers@google.com.
The failing builders are:
  mac_chromium_rel on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/mac_chromium_rel/buil...)

[commit-bot: I haz the power, 2014-05-10 03:37:24]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-05-10 03:37:26]

Failed to apply patch for components/domain_reliability/monitor.cc:
While running patch -p1 --forward --force --no-backup-if-mismatch;
  patching file components/domain_reliability/monitor.cc
  Hunk #1 succeeded at 67 (offset 2 lines).
  Hunk #2 FAILED at 84.
  Hunk #3 succeeded at 132 (offset 2 lines).
  Hunk #4 succeeded at 206 (offset 3 lines).
  1 out of 4 hunks FAILED -- saving rejects to file
components/domain_reliability/monitor.cc.rej

Patch:       components/domain_reliability/monitor.cc
Index: components/domain_reliability/monitor.cc
diff --git a/components/domain_reliability/monitor.cc
b/components/domain_reliability/monitor.cc
index
06d5f55f11a31eb252b831bab8696e1346f6c460..98bfc7326cb3a45b18ae009d4f4a3a832a3f068f
100644
--- a/components/domain_reliability/monitor.cc
+++ b/components/domain_reliability/monitor.cc
@@ -65,7 +65,9 @@ DomainReliabilityMonitor::DomainReliabilityMonitor(
           DomainReliabilityScheduler::Params::GetFromFieldTrialsOrDefaults()),
       dispatcher_(time_.get()),
       uploader_(
-          DomainReliabilityUploader::Create(url_request_context_getter_)) {
+          DomainReliabilityUploader::Create(url_request_context_getter_)),
+      was_cleared_(false),
+      cleared_mode_(MAX_CLEAR_MODE) {
   DCHECK(OnIOThread());
 }
 
@@ -82,14 +84,15 @@ DomainReliabilityMonitor::DomainReliabilityMonitor(
           DomainReliabilityScheduler::Params::GetFromFieldTrialsOrDefaults()),
       dispatcher_(time_.get()),
       uploader_(
-          DomainReliabilityUploader::Create(url_request_context_getter_)) {
+          DomainReliabilityUploader::Create(url_request_context_getter_)),
+      was_cleared_(false),
+      cleared_mode_(MAX_CLEAR_MODE) {
   DCHECK(OnIOThread());
 }
 
 DomainReliabilityMonitor::~DomainReliabilityMonitor() {
   DCHECK(OnIOThread());
-  STLDeleteContainerPairSecondPointers(
-      contexts_.begin(), contexts_.end());
+  ClearContexts();
 }
 
 void DomainReliabilityMonitor::AddBakedInConfigs() {
@@ -128,6 +131,28 @@ void DomainReliabilityMonitor::OnCompleted(net::URLRequest*
request,
   }
 }
 
+void DomainReliabilityMonitor::ClearBrowsingData(
+   DomainReliabilityClearMode mode) {
+  DCHECK(OnIOThread());
+
+  was_cleared_ = true;
+  cleared_mode_ = mode;
+
+  switch (mode) {
+    case CLEAR_BEACONS: {
+      ContextMap::const_iterator it;
+      for (it = contexts_.begin(); it != contexts_.end(); ++it)
+        it->second->ClearBeacons();
+      break;
+    };
+    case CLEAR_CONTEXTS:
+      ClearContexts();
+      break;
+    case MAX_CLEAR_MODE:
+      NOTREACHED();
+  }
+}
+
 DomainReliabilityContext* DomainReliabilityMonitor::AddContextForTesting(
     scoped_ptr<const DomainReliabilityConfig> config) {
   return AddContext(config.Pass());
@@ -179,6 +204,12 @@ DomainReliabilityContext*
DomainReliabilityMonitor::AddContext(
   return map_it.first->second;
 }
 
+void DomainReliabilityMonitor::ClearContexts() {
+  STLDeleteContainerPairSecondPointers(
+      contexts_.begin(), contexts_.end());
+  contexts_.clear();
+}
+
 void DomainReliabilityMonitor::OnRequestLegComplete(
     const RequestInfo& request) {
   if (!request.DefinitelyReachedNetwork())

[Deprecated (see juliatuttle), 2014-05-10 03:47:31]

The CQ bit was checked by ttuttle@chromium.org

[Deprecated (see juliatuttle), 2014-05-10 03:49:34]

The CQ bit was checked by ttuttle@chromium.org

[commit-bot: I haz the power, 2014-05-10 03:50:54]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/ttuttle@chromium.org/238863005/260001

[Deprecated (see juliatuttle), 2014-05-10 04:04:29]

The CQ bit was unchecked by ttuttle@chromium.org

[Deprecated (see juliatuttle), 2014-05-11 00:48:27]

The CQ bit was checked by ttuttle@chromium.org

[commit-bot: I haz the power, 2014-05-11 00:49:17]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/ttuttle@chromium.org/238863005/280001

[Deprecated (see juliatuttle), 2014-05-11 03:15:42]

The CQ bit was checked by ttuttle@chromium.org

[commit-bot: I haz the power, 2014-05-11 03:15:52]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/ttuttle@chromium.org/238863005/300001

[commit-bot: I haz the power, 2014-05-11 04:48:00]

FYI, CQ is re-trying this CL (attempt #1).
Please consider checking whether the failures are real,
and report flakes to chrome-troopers@google.com.
The failing builders are:
  android_aosp on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/android_aosp/builds/7...)
  android_chromium_gn_compile_rel on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/android_chromium_gn_c...)
  android_clang_dbg on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/android_clang_dbg/bui...)
  android_dbg on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/android_dbg/builds/18...)
  ios_dbg_simulator on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/ios_dbg_simulator/bui...)
  ios_rel_device on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/ios_rel_device/builds...)
  linux_chromium_chromeos_clang_dbg on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/linux_chromium_chrome...)
  linux_chromium_chromeos_rel on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/linux_chromium_chrome...)
  linux_chromium_clang_dbg on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/linux_chromium_clang_...)
  linux_chromium_gn_rel on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/linux_chromium_gn_rel...)
  linux_chromium_rel on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/linux_chromium_rel/bu...)
  mac_chromium_compile_dbg on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/mac_chromium_compile_...)
  mac_chromium_rel on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/mac_chromium_rel/buil...)
  win_chromium_compile_dbg on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/win_chromium_compile_...)
  win_chromium_rel on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/win_chromium_rel/buil...)
  win_chromium_x64_rel on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/win_chromium_x64_rel/...)

[commit-bot: I haz the power, 2014-05-11 05:00:02]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-05-11 05:00:03]

Try jobs failed on following builders:
  linux_chromium_chromeos_rel on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/linux_chromium_chrome...)

[Deprecated (see juliatuttle), 2014-05-11 14:29:36]

The CQ bit was checked by ttuttle@chromium.org

[commit-bot: I haz the power, 2014-05-11 14:29:44]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/ttuttle@chromium.org/238863005/300001

[Deprecated (see juliatuttle), 2014-05-11 14:42:27]

The CQ bit was checked by ttuttle@chromium.org

[commit-bot: I haz the power, 2014-05-11 14:42:38]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/ttuttle@chromium.org/238863005/320001

[Deprecated (see juliatuttle), 2014-05-11 15:41:43]

The CQ bit was checked by ttuttle@chromium.org

[commit-bot: I haz the power, 2014-05-11 15:41:47]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/ttuttle@chromium.org/238863005/340001

[commit-bot: I haz the power, 2014-05-11 17:20:47]

FYI, CQ is re-trying this CL (attempt #1).
Please consider checking whether the failures are real,
and report flakes to chrome-troopers@google.com.
The failing builders are:
  ios_rel_device on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/ios_rel_device/builds...)

[commit-bot: I haz the power, 2014-05-11 18:10:34]

Change committed as 269714