Add support for uninstalling components and use it in SupervisedUserWhitelistInstaller.

Add support for uninstalling components and use it in SupervisedUserWhitelistInstaller.

TBR=agl@chromium.org

BUG=436459
Committed: https://crrev.com/1f6657e7f1cf36e7a490c494c0794b124c86b6ec
Cr-Commit-Position: refs/heads/master@{#315246}

[Bernhard Bauer, 2015-02-03 19:16:26]

bauerb@chromium.org changed reviewers:
+ sorin@chromium.org

[Bernhard Bauer, 2015-02-03 19:17:53]

bauerb@chromium.org changed reviewers:
+ treib@chromium.org

[Bernhard Bauer, 2015-02-03 19:17:54]

Please review.

Marc: Supervised user code
Sorin: Component code

Thanks!

[Marc Treib, 2015-02-04 09:55:46]

c/b/supervised_user/ lgtm

https://codereview.chromium.org/879993005/diff/100001/chrome/browser/componen...
File chrome/browser/component_updater/supervised_user_whitelist_installer.cc
(right):

https://codereview.chromium.org/879993005/diff/100001/chrome/browser/componen...
chrome/browser/component_updater/supervised_user_whitelist_installer.cc:156:
auto it = installers_.find(crx_id);
nit: DCHECK_NE(it, installers_.end()) ?

[Bernhard Bauer, 2015-02-04 11:19:49]

New patchsets have been uploaded after l-g-t-m from treib@chromium.org

[Bernhard Bauer, 2015-02-04 11:28:40]

Per discussion with Sorin, pulled out the refcounting changes into a separate CL
(https://codereview.chromium.org/897873002/).

https://codereview.chromium.org/879993005/diff/100001/chrome/browser/componen...
File chrome/browser/component_updater/supervised_user_whitelist_installer.cc
(right):

https://codereview.chromium.org/879993005/diff/100001/chrome/browser/componen...
chrome/browser/component_updater/supervised_user_whitelist_installer.cc:156:
auto it = installers_.find(crx_id);
On 2015/02/04 09:55:46, Marc Treib wrote:
> nit: DCHECK_NE(it, installers_.end()) ?

Done. Not using DCHECK_NE, because AFAICR that didn't work with MSVC (DCHECK_NE
will print the value on failure, and an STL iterator can't be stringified in the
MS implementation).

[Sorin Jianu, 2015-02-05 22:55:36]

Thank you! Let's discuss.

We like the idea of lazy unregistration if the component is in a middle of an
update, in other words, allow the update to continue, then handle the
unregistration, instead of trying to stop the update.

There is some concern related to where to hook up the unregistration code, and
side effects of the current code.

We have made a suggestion on how to do this in a different way.

https://codereview.chromium.org/879993005/diff/160001/chrome/browser/componen...
File chrome/browser/component_updater/supervised_user_whitelist_installer.cc
(right):

https://codereview.chromium.org/879993005/diff/160001/chrome/browser/componen...
chrome/browser/component_updater/supervised_user_whitelist_installer.cc:148:
installers_[crx_id] = installer;
Do we have many crx ids associated with this product? How does this work?

https://codereview.chromium.org/879993005/diff/160001/components/component_up...
File components/component_updater/component_updater_service.cc (right):

https://codereview.chromium.org/879993005/diff/160001/components/component_up...
components/component_updater/component_updater_service.cc:482:
work_items_.erase(it);
We wonder if we could do this in a different way. The idea here is that with the
current design, we'd like to avoid removing items from work_items_, and mutating
the state of the item in this function. Basically, we don't know what else could
or would break in the rest of the code, client-side and server-side included.

For instance, in this case, we change the state of the item to indicate
kNoUpdate, but since an update was available and downloaded, the server expects
a positive ping response back, as we are computing update metrics based on that.
Messing with the state of the item is undesirable.

We suggest that this function just marks the item as unregistered, and the clean
up of work items happens in a different place, where there are no side-effects.
We'll tell you where to possibly hook the code up.'

CrxUpdateItem can maintain a boolean flag to remember the state of the item:
active or unregistered.

https://codereview.chromium.org/879993005/diff/160001/components/component_up...
components/component_updater/component_updater_service.cc:548: 
This is where we could inspect the state of the items which were unregistered,
and clean up.

https://codereview.chromium.org/879993005/diff/160001/components/component_up...
components/component_updater/component_updater_service.cc:807: // If the item
has been removed in the mean time, clean up and return.
The code to clean up an item can be hooked up in the ProcessPendingItems, which
runs a loop to filter the work_items and act accordingly: update, unregister, or
kick off an update check.

https://codereview.chromium.org/879993005/diff/160001/components/component_up...
components/component_updater/component_updater_service.cc:938: // If the item
has been removed in the mean time, return.
Same. The suggest is to centralize the unregistration code in the
ProcessPendingItems, and avoid handling it in different states of the state
machine.

https://codereview.chromium.org/879993005/diff/160001/components/component_up...
File components/component_updater/default_component_installer.cc (right):

https://codereview.chromium.org/879993005/diff/160001/components/component_up...
components/component_updater/default_component_installer.cc:72: if
(should_uninstall_on_destruction_) {
If Chrome is on the exit path, it is possible that the task_runner_ may not run
this task. Therefore, the uninstall code may not run, and the files remain on
the file system. Will this be a problem? Will it cause the component to be
registered again at Chrome boot time? Will these files ever be deleted?

https://codereview.chromium.org/879993005/diff/160001/components/component_up...
components/component_updater/default_component_installer.cc:167:
should_uninstall_on_destruction_ = true;
Would it be possible to run the uninstall code here instead of the destruction
path?

[Bernhard Bauer, 2015-02-05 23:57:35]

Thanks for the review! Some replied below, and I'll make changes tomorrow.

https://codereview.chromium.org/879993005/diff/160001/chrome/browser/componen...
File chrome/browser/component_updater/supervised_user_whitelist_installer.cc
(right):

https://codereview.chromium.org/879993005/diff/160001/chrome/browser/componen...
chrome/browser/component_updater/supervised_user_whitelist_installer.cc:148:
installers_[crx_id] = installer;
On 2015/02/05 22:55:35, Sorin Jianu wrote:
> Do we have many crx ids associated with this product? How does this work?

Yeah, there can be multiple whitelists, each with their own CRX ID.

In terms of functionality, the effect will be the union of all the installed
whitelists.

https://codereview.chromium.org/879993005/diff/160001/components/component_up...
File components/component_updater/component_updater_service.cc (right):

https://codereview.chromium.org/879993005/diff/160001/components/component_up...
components/component_updater/component_updater_service.cc:482:
work_items_.erase(it);
On 2015/02/05 22:55:35, Sorin Jianu wrote:
> We wonder if we could do this in a different way. The idea here is that with
the
> current design, we'd like to avoid removing items from work_items_, and
mutating
> the state of the item in this function. Basically, we don't know what else
could
> or would break in the rest of the code, client-side and server-side included.
> 
> For instance, in this case, we change the state of the item to indicate
> kNoUpdate, but since an update was available and downloaded, the server
expects
> a positive ping response back, as we are computing update metrics based on
that.
> Messing with the state of the item is undesirable.
> 
> We suggest that this function just marks the item as unregistered, and the
clean
> up of work items happens in a different place, where there are no
side-effects.
> We'll tell you where to possibly hook the code up.'
> 
> CrxUpdateItem can maintain a boolean flag to remember the state of the item:
> active or unregistered.

Okay, that makes sense. I'll try to work on that tomorrow.

https://codereview.chromium.org/879993005/diff/160001/components/component_up...
File components/component_updater/default_component_installer.cc (right):

https://codereview.chromium.org/879993005/diff/160001/components/component_up...
components/component_updater/default_component_installer.cc:72: if
(should_uninstall_on_destruction_) {
On 2015/02/05 22:55:35, Sorin Jianu wrote:
> If Chrome is on the exit path, it is possible that the task_runner_ may not
run
> this task. Therefore, the uninstall code may not run, and the files remain on
> the file system. Will this be a problem? Will it cause the component to be
> registered again at Chrome boot time? Will these files ever be deleted?

No, SupervisedUserWhitelistService keeps track of installed whitelists
separately, so it won't register them on the next startup. The files will still
be around, however. Maybe we could delete unknown whitelists on startup?

https://codereview.chromium.org/879993005/diff/160001/components/component_up...
components/component_updater/default_component_installer.cc:167:
should_uninstall_on_destruction_ = true;
On 2015/02/05 22:55:35, Sorin Jianu wrote:
> Would it be possible to run the uninstall code here instead of the destruction
> path?

The problem with that is that when this method is called, the ComponentInstaller
might be currently doing something on its task runner. And even if we make sure
to post the uninstallation task to the same task runner (which is a
SequencedTaskRunner, thereby making sure it will run after the current task
running there), the ComponentUnpacker will also hold a reference to this object
and start installation when it's finished with unpacking, and that could happen
at _any_ point, including after uninstallation has finished.

[Sorin Jianu, 2015-02-06 00:22:05]

Thank you! Will take anther look as soon as the patch is up.

https://codereview.chromium.org/879993005/diff/160001/chrome/browser/componen...
File chrome/browser/component_updater/supervised_user_whitelist_installer.cc
(right):

https://codereview.chromium.org/879993005/diff/160001/chrome/browser/componen...
chrome/browser/component_updater/supervised_user_whitelist_installer.cc:148:
installers_[crx_id] = installer;
On 2015/02/05 23:57:34, Bernhard Bauer wrote:
> On 2015/02/05 22:55:35, Sorin Jianu wrote:
> > Do we have many crx ids associated with this product? How does this work?
> 
> Yeah, there can be multiple whitelists, each with their own CRX ID.
> 
> In terms of functionality, the effect will be the union of all the installed
> whitelists.

Do we have an idea about how many whitelists are we talking about? Can you also
point me out to any design documentation for this product?
We want to make sure that our system can scale to this design. The idea is that
unlike extensions, we expect to manage fewer components. I'd like to get an idea
how far we are pushing the envelope here.

https://codereview.chromium.org/879993005/diff/160001/components/component_up...
File components/component_updater/default_component_installer.cc (right):

https://codereview.chromium.org/879993005/diff/160001/components/component_up...
components/component_updater/default_component_installer.cc:72: if
(should_uninstall_on_destruction_) {
On 2015/02/05 23:57:35, Bernhard Bauer wrote:
> On 2015/02/05 22:55:35, Sorin Jianu wrote:
> > If Chrome is on the exit path, it is possible that the task_runner_ may not
> run
> > this task. Therefore, the uninstall code may not run, and the files remain
on
> > the file system. Will this be a problem? Will it cause the component to be
> > registered again at Chrome boot time? Will these files ever be deleted?
> 
> No, SupervisedUserWhitelistService keeps track of installed whitelists
> separately, so it won't register them on the next startup. The files will
still
> be around, however. Maybe we could delete unknown whitelists on startup?

I think cleaning up on startup could be wise. I don't really know the
registration execution path, so that would be something for you to consider.

https://codereview.chromium.org/879993005/diff/160001/components/component_up...
components/component_updater/default_component_installer.cc:167:
should_uninstall_on_destruction_ = true;
On 2015/02/05 23:57:35, Bernhard Bauer wrote:
> On 2015/02/05 22:55:35, Sorin Jianu wrote:
> > Would it be possible to run the uninstall code here instead of the
destruction
> > path?
> 
> The problem with that is that when this method is called, the
ComponentInstaller
> might be currently doing something on its task runner. And even if we make
sure
> to post the uninstallation task to the same task runner (which is a
> SequencedTaskRunner, thereby making sure it will run after the current task
> running there), the ComponentUnpacker will also hold a reference to this
object
> and start installation when it's finished with unpacking, and that could
happen
> at _any_ point, including after uninstallation has finished.

Right. I wonder if this would work. ComponentInstaller is an interface which
gets called by the service at relevant times. It has an Install method. It could
also have an Uninstall method, and when that method is called, then the service
can release its reference to the installer, and this code can run.

[Bernhard Bauer, 2015-02-06 16:05:05]

PTAL! I now only mark work items as unregistered, then remove them when the
component updater is completely idle. That means that the component updater will
complete its full update cycle if a component is unregistered in the meantime,
which means that cleanup just consists of calling the Uninstall() method.

https://codereview.chromium.org/879993005/diff/160001/chrome/browser/componen...
File chrome/browser/component_updater/supervised_user_whitelist_installer.cc
(right):

https://codereview.chromium.org/879993005/diff/160001/chrome/browser/componen...
chrome/browser/component_updater/supervised_user_whitelist_installer.cc:148:
installers_[crx_id] = installer;
On 2015/02/06 00:22:04, Sorin Jianu wrote:
> On 2015/02/05 23:57:34, Bernhard Bauer wrote:
> > On 2015/02/05 22:55:35, Sorin Jianu wrote:
> > > Do we have many crx ids associated with this product? How does this work?
> > 
> > Yeah, there can be multiple whitelists, each with their own CRX ID.
> > 
> > In terms of functionality, the effect will be the union of all the installed
> > whitelists.
> 
> Do we have an idea about how many whitelists are we talking about? Can you
also
> point me out to any design documentation for this product?
> We want to make sure that our system can scale to this design. The idea is
that
> unlike extensions, we expect to manage fewer components. I'd like to get an
idea
> how far we are pushing the envelope here.

The design doc is at go/unichrome-whitelists-clank.

I would expect the number of whitelists to be single-digit, although it's of
course hard to predict this. In part what we want to do is get an initial
version of this out for dogfooding and gather data based on that. I'll add some
metrics for the number of whitelists and whitelist installation/uninstallation
actions (see https://codereview.chromium.org/905763002/).

Also, what area exactly are you concerned about in terms of performance? Maybe
there is something to optimize there.

https://codereview.chromium.org/879993005/diff/160001/components/component_up...
File components/component_updater/component_updater_service.cc (right):

https://codereview.chromium.org/879993005/diff/160001/components/component_up...
components/component_updater/component_updater_service.cc:548: 
On 2015/02/05 22:55:35, Sorin Jianu wrote:
> This is where we could inspect the state of the items which were unregistered,
> and clean up.

Done.

https://codereview.chromium.org/879993005/diff/160001/components/component_up...
components/component_updater/component_updater_service.cc:807: // If the item
has been removed in the mean time, clean up and return.
On 2015/02/05 22:55:35, Sorin Jianu wrote:
> The code to clean up an item can be hooked up in the ProcessPendingItems,
which
> runs a loop to filter the work_items and act accordingly: update, unregister,
or
> kick off an update check.

Done.

https://codereview.chromium.org/879993005/diff/160001/components/component_up...
components/component_updater/component_updater_service.cc:938: // If the item
has been removed in the mean time, return.
On 2015/02/05 22:55:35, Sorin Jianu wrote:
> Same. The suggest is to centralize the unregistration code in the
> ProcessPendingItems, and avoid handling it in different states of the state
> machine.

Done.

https://codereview.chromium.org/879993005/diff/160001/components/component_up...
File components/component_updater/default_component_installer.cc (right):

https://codereview.chromium.org/879993005/diff/160001/components/component_up...
components/component_updater/default_component_installer.cc:72: if
(should_uninstall_on_destruction_) {
On 2015/02/06 00:22:04, Sorin Jianu wrote:
> On 2015/02/05 23:57:35, Bernhard Bauer wrote:
> > On 2015/02/05 22:55:35, Sorin Jianu wrote:
> > > If Chrome is on the exit path, it is possible that the task_runner_ may
not
> > run
> > > this task. Therefore, the uninstall code may not run, and the files remain
> on
> > > the file system. Will this be a problem? Will it cause the component to be
> > > registered again at Chrome boot time? Will these files ever be deleted?
> > 
> > No, SupervisedUserWhitelistService keeps track of installed whitelists
> > separately, so it won't register them on the next startup. The files will
> still
> > be around, however. Maybe we could delete unknown whitelists on startup?
> 
> I think cleaning up on startup could be wise. I don't really know the
> registration execution path, so that would be something for you to consider.

OK. Something for a followup CL maybe?

https://codereview.chromium.org/879993005/diff/160001/components/component_up...
components/component_updater/default_component_installer.cc:167:
should_uninstall_on_destruction_ = true;
On 2015/02/06 00:22:04, Sorin Jianu wrote:
> On 2015/02/05 23:57:35, Bernhard Bauer wrote:
> > On 2015/02/05 22:55:35, Sorin Jianu wrote:
> > > Would it be possible to run the uninstall code here instead of the
> destruction
> > > path?
> > 
> > The problem with that is that when this method is called, the
> ComponentInstaller
> > might be currently doing something on its task runner. And even if we make
> sure
> > to post the uninstallation task to the same task runner (which is a
> > SequencedTaskRunner, thereby making sure it will run after the current task
> > running there), the ComponentUnpacker will also hold a reference to this
> object
> > and start installation when it's finished with unpacking, and that could
> happen
> > at _any_ point, including after uninstallation has finished.
> 
> Right. I wonder if this would work. ComponentInstaller is an interface which
> gets called by the service at relevant times. It has an Install method. It
could
> also have an Uninstall method, and when that method is called, then the
service
> can release its reference to the installer, and this code can run.

Done.

[Sorin Jianu, 2015-02-06 19:11:58]

Thank you, pretty cool! Main ask here is to refactor a block of code as a member
function, the rest are nit-picks.

https://codereview.chromium.org/879993005/diff/200001/chrome/browser/componen...
File chrome/browser/component_updater/supervised_user_whitelist_installer.cc
(right):

https://codereview.chromium.org/879993005/diff/200001/chrome/browser/componen...
chrome/browser/component_updater/supervised_user_whitelist_installer.cc:152:
ComponentUpdateService::Status status = cus_->UnregisterComponent(crx_id);
can be const

https://codereview.chromium.org/879993005/diff/200001/components/component_up...
File components/component_updater/component_updater_service.cc (right):

https://codereview.chromium.org/879993005/diff/200001/components/component_up...
components/component_updater/component_updater_service.cc:468:
UpdateItems::iterator it = std::find_if(
maybe use auto?

https://codereview.chromium.org/879993005/diff/200001/components/component_up...
components/component_updater/component_updater_service.cc:542: // Uninstall and
remove all unregistered work items.
Can we factor out this code as a member function?

https://codereview.chromium.org/879993005/diff/200001/components/component_up...
components/component_updater/component_updater_service.cc:547: bool success =
owned_item->component.installer->Uninstall();
could be const

https://codereview.chromium.org/879993005/diff/200001/components/component_up...
File components/component_updater/default_component_installer.cc (right):

https://codereview.chromium.org/879993005/diff/200001/components/component_up...
components/component_updater/default_component_installer.cc:212: base::FilePath
base_dir = installer_traits_->GetBaseDirectory();
can be const?

https://codereview.chromium.org/879993005/diff/200001/components/component_up...
components/component_updater/default_component_installer.cc:214:
std::vector<base::FilePath> paths;
Is the variable |paths| used in this function?

[Bernhard Bauer, 2015-02-06 22:49:03]

Thanks for the review!

https://codereview.chromium.org/879993005/diff/200001/chrome/browser/componen...
File chrome/browser/component_updater/supervised_user_whitelist_installer.cc
(right):

https://codereview.chromium.org/879993005/diff/200001/chrome/browser/componen...
chrome/browser/component_updater/supervised_user_whitelist_installer.cc:152:
ComponentUpdateService::Status status = cus_->UnregisterComponent(crx_id);
On 2015/02/06 19:11:58, Sorin Jianu wrote:
> can be const

Done.

https://codereview.chromium.org/879993005/diff/200001/components/component_up...
File components/component_updater/component_updater_service.cc (right):

https://codereview.chromium.org/879993005/diff/200001/components/component_up...
components/component_updater/component_updater_service.cc:468:
UpdateItems::iterator it = std::find_if(
On 2015/02/06 19:11:58, Sorin Jianu wrote:
> maybe use auto?

Done.

https://codereview.chromium.org/879993005/diff/200001/components/component_up...
components/component_updater/component_updater_service.cc:542: // Uninstall and
remove all unregistered work items.
On 2015/02/06 19:11:58, Sorin Jianu wrote:
> Can we factor out this code as a member function?

Done.

https://codereview.chromium.org/879993005/diff/200001/components/component_up...
components/component_updater/component_updater_service.cc:547: bool success =
owned_item->component.installer->Uninstall();
On 2015/02/06 19:11:58, Sorin Jianu wrote:
> could be const

Done.

https://codereview.chromium.org/879993005/diff/200001/components/component_up...
File components/component_updater/default_component_installer.cc (right):

https://codereview.chromium.org/879993005/diff/200001/components/component_up...
components/component_updater/default_component_installer.cc:212: base::FilePath
base_dir = installer_traits_->GetBaseDirectory();
On 2015/02/06 19:11:58, Sorin Jianu wrote:
> can be const?

Done.

https://codereview.chromium.org/879993005/diff/200001/components/component_up...
components/component_updater/default_component_installer.cc:214:
std::vector<base::FilePath> paths;
On 2015/02/06 19:11:58, Sorin Jianu wrote:
> Is the variable |paths| used in this function?

Indeed, that was left over from an earlier version. Removed!

[Sorin Jianu, 2015-02-06 23:00:30]

Thank you!

https://codereview.chromium.org/879993005/diff/240001/components/component_up...
File components/component_updater/component_updater_service.cc (right):

https://codereview.chromium.org/879993005/diff/240001/components/component_up...
components/component_updater/component_updater_service.cc:539:
UninstallUnregisteredItems();
Need to move this call at line 546, I will explain why in 1 hr.

[Sorin Jianu, 2015-02-07 02:20:36]

lgtm

Thank you!

https://codereview.chromium.org/879993005/diff/260001/components/component_up...
File components/component_updater/component_updater_service.cc (right):

https://codereview.chromium.org/879993005/diff/260001/components/component_up...
components/component_updater/component_updater_service.cc:545:
UninstallUnregisteredItems();
Thank you for moving the call so that the uninstall happens after the update of
the component. The idea here is that when we give out an update to a component,
we also expect to hear back from the the component update service, so we know if
the update succeeded or failed. Therefore, the update must be processed before
the uninstall in the case where the call to unregistered a component arrived
while the component was in the loop of being checked for updates.

[Bernhard Bauer, 2015-02-08 13:50:52]

bauerb@chromium.org changed reviewers:
+ agl@chromium.org

[Bernhard Bauer, 2015-02-08 13:52:57]

Adding Adam for chrome/browser/net/ OWNERS TBR (updating CrlSetFetcher to
implement a new method in the interface).

https://codereview.chromium.org/879993005/diff/260001/components/component_up...
File components/component_updater/component_updater_service.cc (right):

https://codereview.chromium.org/879993005/diff/260001/components/component_up...
components/component_updater/component_updater_service.cc:545:
UninstallUnregisteredItems();
On 2015/02/07 02:20:35, Sorin Jianu wrote:
> Thank you for moving the call so that the uninstall happens after the update
of
> the component. The idea here is that when we give out an update to a
component,
> we also expect to hear back from the the component update service, so we know
if
> the update succeeded or failed. Therefore, the update must be processed before
> the uninstall in the case where the call to unregistered a component arrived
> while the component was in the loop of being checked for updates.

Makes sense. Thanks for the explanation!

[Bernhard Bauer, 2015-02-08 13:53:06]

The CQ bit was checked by bauerb@chromium.org

[commit-bot: I haz the power, 2015-02-08 13:53:34]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/879993005/260001

[commit-bot: I haz the power, 2015-02-08 15:06:59]

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

[commit-bot: I haz the power, 2015-02-08 15:07:00]

Try jobs failed on following builders:
  linux_chromium_rel_ng on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[Bernhard Bauer, 2015-02-08 16:59:14]

The CQ bit was checked by bauerb@chromium.org

[commit-bot: I haz the power, 2015-02-08 16:59:58]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/879993005/260001

[commit-bot: I haz the power, 2015-02-08 18:12:24]

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

[commit-bot: I haz the power, 2015-02-08 18:12:25]

Try jobs failed on following builders:
  linux_chromium_rel_ng on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[Bernhard Bauer, 2015-02-08 23:17:55]

New patchsets have been uploaded after l-g-t-m from sorin@chromium.org

[Bernhard Bauer, 2015-02-08 23:20:40]

https://codereview.chromium.org/879993005/diff/280001/components/component_up...
File components/component_updater/component_updater_service.cc (right):

https://codereview.chromium.org/879993005/diff/280001/components/component_up...
components/component_updater/component_updater_service.cc:513: return
blocking_task_runner_;
I had to make this change because of failing tests.
config_->GetSequencedTaskRunner() returns a different task runner every time it
is called (because it gets a new sequence token), which meant that the default
component installer was running on a different thread than what it expected.

[Bernhard Bauer, 2015-02-08 23:20:48]

The CQ bit was checked by bauerb@chromium.org

[commit-bot: I haz the power, 2015-02-08 23:21:53]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/879993005/280001

[commit-bot: I haz the power, 2015-02-09 00:00:38]

Committed patchset #15 (id:280001)

[commit-bot: I haz the power, 2015-02-09 00:01:30]

Patchset 15 (id:??) landed as
https://crrev.com/1f6657e7f1cf36e7a490c494c0794b124c86b6ec
Cr-Commit-Position: refs/heads/master@{#315246}