Add non-blocking sync code to ProfileSyncService

Add non-blocking sync code to ProfileSyncService

Adds support for non-blocking sync to the ProfileSyncService and related
classes.  This continues the work of r258390 and r259921.  Like those
patches, it is not expected to have any impact on behavior.

Introduces ProfileSyncService::RegisterNonBlockingType().  This function
will act as an alternative to RegisterDataTypeController().

Adds some support for these non-blocking types.  Adds a special
case to the code that generates the 'type status' table on the
about:sync page.

Instantiates and copies a SyncCoreProxy object to the ProfileSyncService
as backend initialization completes.  This will be an important part of
non-blocking data type initialization, once that functionality is
supported.

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

[rlarocque, 2014-03-28 18:10:14]

Here's the next patch in the series.  I think I manged to avoid rebase issues
this time.

Please review.

https://codereview.chromium.org/217183003/diff/1/sync/internal_api/public/syn...
File sync/internal_api/public/sync_manager.h (right):

https://codereview.chromium.org/217183003/diff/1/sync/internal_api/public/syn...
sync/internal_api/public/sync_manager.h:336: virtual
base::WeakPtr<syncer::SyncCore> GetSyncCore() = 0;
In case you're wondering, I changed my mind on this when I realized that
sync_backend_host_core.h wasn't allowed to #include sync_core.h, and that I had
to return a WeakPtr here so I could forward declare it.

[rlarocque, 2014-04-02 22:30:01]

ping.

[Nicolas Zea, 2014-04-02 23:19:05]

https://codereview.chromium.org/217183003/diff/1/chrome/browser/sync/glue/syn...
File chrome/browser/sync/glue/sync_backend_host_core.cc (right):

https://codereview.chromium.org/217183003/diff/1/chrome/browser/sync/glue/syn...
chrome/browser/sync/glue/sync_backend_host_core.cc:488: sync_core.get();
I don't think this is necessary. A weak pointer always belongs to the thread it
was created on (see the constructor for SequenceCheckerImpl). It's only verified
when IsValid is checked, but the ownership is assigned at construction time.

https://codereview.chromium.org/217183003/diff/1/chrome/browser/sync/glue/syn...
File chrome/browser/sync/glue/sync_backend_host_impl.cc (right):

https://codereview.chromium.org/217183003/diff/1/chrome/browser/sync/glue/syn...
chrome/browser/sync/glue/sync_backend_host_impl.cc:547: void
SyncBackendHostImpl::UpdateRegisteredInvalidationTypes() {
How about changing this to UpdateEnabledTypes(directory types, nonblocking
types), and having that always invoke UpdateRegisteredInvalidationIds? That way
you don't have to remember to also call that in the two spots you've got.

https://codereview.chromium.org/217183003/diff/1/chrome/browser/sync/glue/syn...
chrome/browser/sync/glue/sync_backend_host_impl.cc:586:
base::WeakPtr<syncer::SyncCore> sync_core) {
What do you think about creating the SyncCoreProxy in the core on the sync
thread, and having it get posted back to the UI thread? That way the SyncCore
itself doesn't need to be passed around.

https://codereview.chromium.org/217183003/diff/1/chrome/browser/sync/profile_...
File chrome/browser/sync/profile_sync_service.cc (right):

https://codereview.chromium.org/217183003/diff/1/chrome/browser/sync/profile_...
chrome/browser/sync/profile_sync_service.cc:360: off_thread_types_.Put(type);
Presumably this is where we could kick off the startup for this type if it's
preferred? Add a comment?

https://codereview.chromium.org/217183003/diff/1/chrome/browser/sync/profile_...
chrome/browser/sync/profile_sync_service.cc:556:
GetPreferredDirectoryDataTypes();
Why not GetPreferredDataTypes? Encryption isn't something tied to directory vs
nonblocking, right?

https://codereview.chromium.org/217183003/diff/1/chrome/browser/sync/profile_...
chrome/browser/sync/profile_sync_service.cc:587: if
(!GetPreferredDirectoryDataTypes().Has(type)) {
Here too. If a nonblocking type requests sync startup, shouldn't we start up?

https://codereview.chromium.org/217183003/diff/1/chrome/browser/sync/profile_...
chrome/browser/sync/profile_sync_service.cc:949:
backend_->SetPreferredNonBlockingTypes(GetPreferredNonBlockingDataTypes());
It's not clear to me why the backend needs to know about the preferred
nonblocking types

https://codereview.chromium.org/217183003/diff/1/chrome/browser/sync/profile_...
chrome/browser/sync/profile_sync_service.cc:1685: const syncer::ModelTypeSet
preferred_types = GetPreferredDirectoryDataTypes();
ActiveTypes only cares about whether they're running or not, not whether they're
directory or nonblocking. Why change this?

https://codereview.chromium.org/217183003/diff/1/chrome/browser/sync/profile_...
File chrome/browser/sync/profile_sync_service.h (right):

https://codereview.chromium.org/217183003/diff/1/chrome/browser/sync/profile_...
chrome/browser/sync/profile_sync_service.h:911: // List of types that may be
synced off-thread.
nit: prefer not using off-thread as a term. Directory types can be off-thread
too. Why not just call these non_blocking_types?

[rlarocque, 2014-04-03 01:03:46]

Patch updated.  PTAL.

https://codereview.chromium.org/217183003/diff/1/chrome/browser/sync/glue/syn...
File chrome/browser/sync/glue/sync_backend_host_core.cc (right):

https://codereview.chromium.org/217183003/diff/1/chrome/browser/sync/glue/syn...
chrome/browser/sync/glue/sync_backend_host_core.cc:488: sync_core.get();
On 2014/04/02 23:19:05, Nicolas Zea wrote:
> I don't think this is necessary. A weak pointer always belongs to the thread
it
> was created on (see the constructor for SequenceCheckerImpl). It's only
verified
> when IsValid is checked, but the ownership is assigned at construction time.

IIRC, I added this statement because it helped me debug a crash, then decided to
leave it in since it was helpful.

The WeakReference::Flag constructor calls DetachFromSequence() on its
SequenceChecker.  Wouldn't that undo the association created in the
SequenceChecker's construction?

https://codereview.chromium.org/217183003/diff/1/chrome/browser/sync/glue/syn...
File chrome/browser/sync/glue/sync_backend_host_impl.cc (right):

https://codereview.chromium.org/217183003/diff/1/chrome/browser/sync/glue/syn...
chrome/browser/sync/glue/sync_backend_host_impl.cc:547: void
SyncBackendHostImpl::UpdateRegisteredInvalidationTypes() {
On 2014/04/02 23:19:05, Nicolas Zea wrote:
> How about changing this to UpdateEnabledTypes(directory types, nonblocking
> types), and having that always invoke UpdateRegisteredInvalidationIds? That
way
> you don't have to remember to also call that in the two spots you've got.

I don't understand this suggestion.  We'd still need call this function in both
spots, because there are two scenarios where the list of registered types must
be changed.

https://codereview.chromium.org/217183003/diff/1/chrome/browser/sync/glue/syn...
chrome/browser/sync/glue/sync_backend_host_impl.cc:586:
base::WeakPtr<syncer::SyncCore> sync_core) {
On 2014/04/02 23:19:05, Nicolas Zea wrote:
> What do you think about creating the SyncCoreProxy in the core on the sync
> thread, and having it get posted back to the UI thread? That way the SyncCore
> itself doesn't need to be passed around.

I think that's a good idea.  Done.

https://codereview.chromium.org/217183003/diff/1/chrome/browser/sync/profile_...
File chrome/browser/sync/profile_sync_service.cc (right):

https://codereview.chromium.org/217183003/diff/1/chrome/browser/sync/profile_...
chrome/browser/sync/profile_sync_service.cc:360: off_thread_types_.Put(type);
On 2014/04/02 23:19:05, Nicolas Zea wrote:
> Presumably this is where we could kick off the startup for this type if it's
> preferred? Add a comment?

Nope, not here.  Registration is something that should happen with every init of
the ProfileSyncService.  This function is equivalent to
RegisterDataTypeController.

Startup will be much more complicated.  We might need to add an extra class to
track all the state involved.  

We can't start up until both the type and the backend are ready.  These are two
independent events that could happen in any order.  We'll also need some
edge-triggered logic to handle types being preferred or un-preferred.  So there
will be at least three different code paths that can trigger a startup.

https://codereview.chromium.org/217183003/diff/1/chrome/browser/sync/profile_...
chrome/browser/sync/profile_sync_service.cc:556:
GetPreferredDirectoryDataTypes();
On 2014/04/02 23:19:05, Nicolas Zea wrote:
> Why not GetPreferredDataTypes? Encryption isn't something tied to directory vs
> nonblocking, right?

Good point.  Fixed.

https://codereview.chromium.org/217183003/diff/1/chrome/browser/sync/profile_...
chrome/browser/sync/profile_sync_service.cc:587: if
(!GetPreferredDirectoryDataTypes().Has(type)) {
On 2014/04/02 23:19:05, Nicolas Zea wrote:
> Here too. If a nonblocking type requests sync startup, shouldn't we start up?

Maybe.  The non-blocking types won't be as badly affected by deferred init as
directory types.  I don't foresee them needing to request sync startup.

I guess it does not harm to support it, though.  I've updated it to
GetPreferredTypes() for now.

https://codereview.chromium.org/217183003/diff/1/chrome/browser/sync/profile_...
chrome/browser/sync/profile_sync_service.cc:949:
backend_->SetPreferredNonBlockingTypes(GetPreferredNonBlockingDataTypes());
On 2014/04/02 23:19:05, Nicolas Zea wrote:
> It's not clear to me why the backend needs to know about the preferred
> nonblocking types

I was surprised to learn about this, too.

We want non-blocking types to receive invalidations like any other type.  But
the set of registered ObjectIds lives in the SyncBackendHost.  This call lets
the SyncBackendHost know that it should register these types to receive
invalidations.

There's probably a better solution than this.  Maybe invalidations should be
separated from the SyncBackendHost.  But that would be problematic, since the
SyncBackendHost manages the SyncBackendHostCore, which is where those
invalidations need to be forwarded eventually.  

I'm interested in fixing this, but I can't think of any simple way to do it.

https://codereview.chromium.org/217183003/diff/1/chrome/browser/sync/profile_...
chrome/browser/sync/profile_sync_service.cc:1685: const syncer::ModelTypeSet
preferred_types = GetPreferredDirectoryDataTypes();
On 2014/04/02 23:19:05, Nicolas Zea wrote:
> ActiveTypes only cares about whether they're running or not, not whether
they're
> directory or nonblocking. Why change this?

I thought this was used only for construction of the about:sync status, and that
it was related to DTC status.  Looks like that was wrong.

I've changed it back.

By the way, what is this actually used for?

https://codereview.chromium.org/217183003/diff/1/chrome/browser/sync/profile_...
File chrome/browser/sync/profile_sync_service.h (right):

https://codereview.chromium.org/217183003/diff/1/chrome/browser/sync/profile_...
chrome/browser/sync/profile_sync_service.h:911: // List of types that may be
synced off-thread.
On 2014/04/02 23:19:05, Nicolas Zea wrote:
> nit: prefer not using off-thread as a term. Directory types can be off-thread
> too. Why not just call these non_blocking_types?

My bad.  I think we discussed this in the review for a previous patch in the
stack.  I forgot to update the name here.

Fixed.

[Nicolas Zea, 2014-04-03 17:52:13]

https://codereview.chromium.org/217183003/diff/1/chrome/browser/sync/glue/syn...
File chrome/browser/sync/glue/sync_backend_host_core.cc (right):

https://codereview.chromium.org/217183003/diff/1/chrome/browser/sync/glue/syn...
chrome/browser/sync/glue/sync_backend_host_core.cc:488: sync_core.get();
On 2014/04/03 01:03:46, rlarocque wrote:
> On 2014/04/02 23:19:05, Nicolas Zea wrote:
> > I don't think this is necessary. A weak pointer always belongs to the thread
> it
> > was created on (see the constructor for SequenceCheckerImpl). It's only
> verified
> > when IsValid is checked, but the ownership is assigned at construction time.
> 
> IIRC, I added this statement because it helped me debug a crash, then decided
to
> leave it in since it was helpful.
> 
> The WeakReference::Flag constructor calls DetachFromSequence() on its
> SequenceChecker.  Wouldn't that undo the association created in the
> SequenceChecker's construction?

Huh, I missed that. Fair enough then.

https://codereview.chromium.org/217183003/diff/1/chrome/browser/sync/glue/syn...
File chrome/browser/sync/glue/sync_backend_host_impl.cc (right):

https://codereview.chromium.org/217183003/diff/1/chrome/browser/sync/glue/syn...
chrome/browser/sync/glue/sync_backend_host_impl.cc:547: void
SyncBackendHostImpl::UpdateRegisteredInvalidationTypes() {
On 2014/04/03 01:03:46, rlarocque wrote:
> On 2014/04/02 23:19:05, Nicolas Zea wrote:
> > How about changing this to UpdateEnabledTypes(directory types, nonblocking
> > types), and having that always invoke UpdateRegisteredInvalidationIds? That
> way
> > you don't have to remember to also call that in the two spots you've got.
> 
> I don't understand this suggestion.  We'd still need call this function in
both
> spots, because there are two scenarios where the list of registered types must
> be changed.

Yeah, I think I was still thinking of the set of enabled types as one enumset.
Disregard.

https://codereview.chromium.org/217183003/diff/1/chrome/browser/sync/profile_...
File chrome/browser/sync/profile_sync_service.cc (right):

https://codereview.chromium.org/217183003/diff/1/chrome/browser/sync/profile_...
chrome/browser/sync/profile_sync_service.cc:949:
backend_->SetPreferredNonBlockingTypes(GetPreferredNonBlockingDataTypes());
On 2014/04/03 01:03:46, rlarocque wrote:
> On 2014/04/02 23:19:05, Nicolas Zea wrote:
> > It's not clear to me why the backend needs to know about the preferred
> > nonblocking types
> 
> I was surprised to learn about this, too.
> 
> We want non-blocking types to receive invalidations like any other type.  But
> the set of registered ObjectIds lives in the SyncBackendHost.  This call lets
> the SyncBackendHost know that it should register these types to receive
> invalidations.
> 
> There's probably a better solution than this.  Maybe invalidations should be
> separated from the SyncBackendHost.  But that would be problematic, since the
> SyncBackendHost manages the SyncBackendHostCore, which is where those
> invalidations need to be forwarded eventually.  
> 
> I'm interested in fixing this, but I can't think of any simple way to do it.

But why is this different from directory types? Do we care about registering for
invalidations before we actually start syncing the non-blocking type? Otherwise,
can't we wait to register for invalidations for that type until we're actually
syncing it?

https://codereview.chromium.org/217183003/diff/1/chrome/browser/sync/profile_...
chrome/browser/sync/profile_sync_service.cc:1685: const syncer::ModelTypeSet
preferred_types = GetPreferredDirectoryDataTypes();
On 2014/04/03 01:03:46, rlarocque wrote:
> On 2014/04/02 23:19:05, Nicolas Zea wrote:
> > ActiveTypes only cares about whether they're running or not, not whether
> they're
> > directory or nonblocking. Why change this?
> 
> I thought this was used only for construction of the about:sync status, and
that
> it was related to DTC status.  Looks like that was wrong.
> 
> I've changed it back.
> 
> By the way, what is this actually used for?

Anything that cares about what types are actually running. This affects sync's
internal error handling as well as UI that cares of sync types (like those using
favicons or tab data).

[rlarocque, 2014-04-03 19:57:02]

https://codereview.chromium.org/217183003/diff/1/chrome/browser/sync/profile_...
File chrome/browser/sync/profile_sync_service.cc (right):

https://codereview.chromium.org/217183003/diff/1/chrome/browser/sync/profile_...
chrome/browser/sync/profile_sync_service.cc:949:
backend_->SetPreferredNonBlockingTypes(GetPreferredNonBlockingDataTypes());
On 2014/04/03 17:52:15, Nicolas Zea wrote:
> On 2014/04/03 01:03:46, rlarocque wrote:
> > On 2014/04/02 23:19:05, Nicolas Zea wrote:
> > > It's not clear to me why the backend needs to know about the preferred
> > > nonblocking types
> > 
> > I was surprised to learn about this, too.
> > 
> > We want non-blocking types to receive invalidations like any other type. 
But
> > the set of registered ObjectIds lives in the SyncBackendHost.  This call
lets
> > the SyncBackendHost know that it should register these types to receive
> > invalidations.
> > 
> > There's probably a better solution than this.  Maybe invalidations should be
> > separated from the SyncBackendHost.  But that would be problematic, since
the
> > SyncBackendHost manages the SyncBackendHostCore, which is where those
> > invalidations need to be forwarded eventually.  
> > 
> > I'm interested in fixing this, but I can't think of any simple way to do it.
> 
> But why is this different from directory types? Do we care about registering
for
> invalidations before we actually start syncing the non-blocking type?
Otherwise,
> can't we wait to register for invalidations for that type until we're actually
> syncing it?

Directory types register for invalidations once they're configured.  Now that we
have reliable invaliations, it's debatable whether or not it's necessary to wait
until configuration is done before registering them.  However, that's the way
it's always been, and there is some logic to it.  

Non-blocking types would have some difficulty registering only after they've
configured.  Non-blocking types' concept of configuration is less well-defined. 
There's currently no plan post a task to the SyncBackendHost / UI thread to
signal that their configuration is complete, like
FinishConfigureDataTypesOnFrontendLoop does now for directory types.  

I guess it would make more sense to delay the registration of the non-blocking
types until all the conditions for sync are met (ie. type is preferred, backend
is initialized, and model type code has indicated it is ready).  We'd still need
a separate hook into the SyncBackendHost, though.

[Nicolas Zea, 2014-04-03 20:11:58]

On 2014/04/03 19:57:02, rlarocque wrote:
>
https://codereview.chromium.org/217183003/diff/1/chrome/browser/sync/profile_...
> File chrome/browser/sync/profile_sync_service.cc (right):
> 
>
https://codereview.chromium.org/217183003/diff/1/chrome/browser/sync/profile_...
> chrome/browser/sync/profile_sync_service.cc:949:
> backend_->SetPreferredNonBlockingTypes(GetPreferredNonBlockingDataTypes());
> On 2014/04/03 17:52:15, Nicolas Zea wrote:
> > On 2014/04/03 01:03:46, rlarocque wrote:
> > > On 2014/04/02 23:19:05, Nicolas Zea wrote:
> > > > It's not clear to me why the backend needs to know about the preferred
> > > > nonblocking types
> > > 
> > > I was surprised to learn about this, too.
> > > 
> > > We want non-blocking types to receive invalidations like any other type. 
> But
> > > the set of registered ObjectIds lives in the SyncBackendHost.  This call
> lets
> > > the SyncBackendHost know that it should register these types to receive
> > > invalidations.
> > > 
> > > There's probably a better solution than this.  Maybe invalidations should
be
> > > separated from the SyncBackendHost.  But that would be problematic, since
> the
> > > SyncBackendHost manages the SyncBackendHostCore, which is where those
> > > invalidations need to be forwarded eventually.  
> > > 
> > > I'm interested in fixing this, but I can't think of any simple way to do
it.
> > 
> > But why is this different from directory types? Do we care about registering
> for
> > invalidations before we actually start syncing the non-blocking type?
> Otherwise,
> > can't we wait to register for invalidations for that type until we're
actually
> > syncing it?
> 
> Directory types register for invalidations once they're configured.  Now that
we
> have reliable invaliations, it's debatable whether or not it's necessary to
wait
> until configuration is done before registering them.  However, that's the way
> it's always been, and there is some logic to it.  
> 
> Non-blocking types would have some difficulty registering only after they've
> configured.  Non-blocking types' concept of configuration is less
well-defined. 
> There's currently no plan post a task to the SyncBackendHost / UI thread to
> signal that their configuration is complete, like
> FinishConfigureDataTypesOnFrontendLoop does now for directory types.  
> 
> I guess it would make more sense to delay the registration of the non-blocking
> types until all the conditions for sync are met (ie. type is preferred,
backend
> is initialized, and model type code has indicated it is ready).  We'd still
need
> a separate hook into the SyncBackendHost, though.

The sync thread is the only place we'll actually know which types are
ready/running or not, right (via the ModelTypeRegistry)? Why not have the
ModelTypeRegistry inform the SyncBackendHostImpl when a type registers itself
via the SyncCoreProxy, so we have a more reliable notion of the type's status?

That said, I wonder if we should just leave this part off for now, and land it
when the startup logic is more fleshed out. I also wonder how the startup is
going to interact with sync-triggered configuration, e.g. migrations, datatype
errors, etc, and how that should affect invalidations.

[rlarocque, 2014-04-03 20:21:48]

On 2014/04/03 20:11:58, Nicolas Zea wrote:
> On 2014/04/03 19:57:02, rlarocque wrote:
> >
>
https://codereview.chromium.org/217183003/diff/1/chrome/browser/sync/profile_...
> > File chrome/browser/sync/profile_sync_service.cc (right):
> > 
> >
>
https://codereview.chromium.org/217183003/diff/1/chrome/browser/sync/profile_...
> > chrome/browser/sync/profile_sync_service.cc:949:
> > backend_->SetPreferredNonBlockingTypes(GetPreferredNonBlockingDataTypes());
> > On 2014/04/03 17:52:15, Nicolas Zea wrote:
> > > On 2014/04/03 01:03:46, rlarocque wrote:
> > > > On 2014/04/02 23:19:05, Nicolas Zea wrote:
> > > > > It's not clear to me why the backend needs to know about the preferred
> > > > > nonblocking types
> > > > 
> > > > I was surprised to learn about this, too.
> > > > 
> > > > We want non-blocking types to receive invalidations like any other type.

> > But
> > > > the set of registered ObjectIds lives in the SyncBackendHost.  This call
> > lets
> > > > the SyncBackendHost know that it should register these types to receive
> > > > invalidations.
> > > > 
> > > > There's probably a better solution than this.  Maybe invalidations
should
> be
> > > > separated from the SyncBackendHost.  But that would be problematic,
since
> > the
> > > > SyncBackendHost manages the SyncBackendHostCore, which is where those
> > > > invalidations need to be forwarded eventually.  
> > > > 
> > > > I'm interested in fixing this, but I can't think of any simple way to do
> it.
> > > 
> > > But why is this different from directory types? Do we care about
registering
> > for
> > > invalidations before we actually start syncing the non-blocking type?
> > Otherwise,
> > > can't we wait to register for invalidations for that type until we're
> actually
> > > syncing it?
> > 
> > Directory types register for invalidations once they're configured.  Now
that
> we
> > have reliable invaliations, it's debatable whether or not it's necessary to
> wait
> > until configuration is done before registering them.  However, that's the
way
> > it's always been, and there is some logic to it.  
> > 
> > Non-blocking types would have some difficulty registering only after they've
> > configured.  Non-blocking types' concept of configuration is less
> well-defined. 
> > There's currently no plan post a task to the SyncBackendHost / UI thread to
> > signal that their configuration is complete, like
> > FinishConfigureDataTypesOnFrontendLoop does now for directory types.  
> > 
> > I guess it would make more sense to delay the registration of the
non-blocking
> > types until all the conditions for sync are met (ie. type is preferred,
> backend
> > is initialized, and model type code has indicated it is ready).  We'd still
> need
> > a separate hook into the SyncBackendHost, though.
> 
> The sync thread is the only place we'll actually know which types are
> ready/running or not, right (via the ModelTypeRegistry)? Why not have the
> ModelTypeRegistry inform the SyncBackendHostImpl when a type registers itself
> via the SyncCoreProxy, so we have a more reliable notion of the type's status?
> 
> That said, I wonder if we should just leave this part off for now, and land it
> when the startup logic is more fleshed out. I also wonder how the startup is
> going to interact with sync-triggered configuration, e.g. migrations, datatype
> errors, etc, and how that should affect invalidations.

OK.  I'll revert these parts and we can come back to this later.

[rlarocque, 2014-04-03 20:30:16]

I've reverted all of the invalidations-related parts.  PTAL.

[Nicolas Zea, 2014-04-03 20:36:08]

lgtm

https://codereview.chromium.org/217183003/diff/60001/chrome/browser/sync/prof...
File chrome/browser/sync/profile_sync_service.cc (right):

https://codereview.chromium.org/217183003/diff/60001/chrome/browser/sync/prof...
chrome/browser/sync/profile_sync_service.cc:1227: const syncer::ModelTypeSet
types = GetPreferredDirectoryDataTypes();
It's unclear to me how we should trigger reconfiguration of nonblocking types
here and below. Perhaps add a TODO?

[rlarocque, 2014-04-03 20:58:37]

The CQ bit was checked by rlarocque@chromium.org

[commit-bot: I haz the power, 2014-04-03 21:00:14]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/rlarocque@chromium.org/217183003/80001

[commit-bot: I haz the power, 2014-04-03 22:15:50]

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

[commit-bot: I haz the power, 2014-04-03 22:15:51]

Try jobs failed on following builders:
  tryserver.chromium on linux_chromium_chromeos_rel

[rlarocque, 2014-04-03 22:26:09]

The CQ bit was checked by rlarocque@chromium.org

[commit-bot: I haz the power, 2014-04-03 22:28:17]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/rlarocque@chromium.org/217183003/80001

[commit-bot: I haz the power, 2014-04-04 00:06:17]

Change committed as 261590