Implement BrowserStateKeyedServiceFactory::GetAssociatedPrefRegistry()

Implement BrowserStateKeyedServiceFactory::GetAssociatedPrefRegistry()

As part of this CL, the dependency of //components/user_prefs
on //content is removed.

TBR=rlp, estade

Committed: https://crrev.com/3b2d62da970372d204fe938da56ee4a662445ba8
Cr-Commit-Position: refs/heads/master@{#325401}

[droger, 2015-04-15 15:02:43]

Patchset #1 (id:1) has been deleted

[droger, 2015-04-15 15:02:49]

Patchset #1 (id:20001) has been deleted

[droger, 2015-04-15 15:04:37]

droger@chromium.org changed reviewers:
+ sdefresne@chromium.org

[droger, 2015-04-15 15:04:37]

sdefresne: please do a first pass on the CL.

[sdefresne, 2015-04-15 15:14:32]

Can you fix the compilation and checks whether the compilation succeeded without
the dependency on dynamic_allocations (I suspect it won't).

https://codereview.chromium.org/1062083003/diff/40001/components/keyed_servic...
File components/keyed_service/content/browser_context_keyed_base_factory.cc
(right):

https://codereview.chromium.org/1062083003/diff/40001/components/keyed_servic...
components/keyed_service/content/browser_context_keyed_base_factory.cc:59:
PrefService* prefs = user_prefs::UserPrefs::Get(
style plus compilation fix:

PrefService* prefs = user_prefs::UserPrefs::Get(context);

https://codereview.chromium.org/1062083003/diff/40001/components/user_prefs.gypi
File components/user_prefs.gypi (left):

https://codereview.chromium.org/1062083003/diff/40001/components/user_prefs.g...
components/user_prefs.gypi:13:
'../base/third_party/dynamic_annotations/dynamic_annotations.gyp:dynamic_annotations',
I'm not sure you can remove this dependency. It is required if you directly or
indirectly depends on some ON_TRACE_... macros IIRC.

[droger, 2015-04-15 15:18:37]

Thanks.

https://codereview.chromium.org/1062083003/diff/40001/components/keyed_servic...
File components/keyed_service/content/browser_context_keyed_base_factory.cc
(right):

https://codereview.chromium.org/1062083003/diff/40001/components/keyed_servic...
components/keyed_service/content/browser_context_keyed_base_factory.cc:59:
PrefService* prefs = user_prefs::UserPrefs::Get(
On 2015/04/15 15:14:31, sdefresne wrote:
> style plus compilation fix:
> 
> PrefService* prefs = user_prefs::UserPrefs::Get(context);

Done.

https://codereview.chromium.org/1062083003/diff/40001/components/user_prefs.gypi
File components/user_prefs.gypi (left):

https://codereview.chromium.org/1062083003/diff/40001/components/user_prefs.g...
components/user_prefs.gypi:13:
'../base/third_party/dynamic_annotations/dynamic_annotations.gyp:dynamic_annotations',
On 2015/04/15 15:14:31, sdefresne wrote:
> I'm not sure you can remove this dependency. It is required if you directly or
> indirectly depends on some ON_TRACE_... macros IIRC.

We'll see :)

[droger, 2015-04-15 15:19:20]

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

[droger, 2015-04-15 15:19:21]

+ bauerb for components/user_prefs

[sdefresne, 2015-04-15 15:22:41]

lgtm

[Bernhard Bauer, 2015-04-15 15:28:13]

https://codereview.chromium.org/1062083003/diff/60001/components/keyed_servic...
File components/keyed_service/ios/browser_state_keyed_service_factory.cc
(right):

https://codereview.chromium.org/1062083003/diff/60001/components/keyed_servic...
components/keyed_service/ios/browser_state_keyed_service_factory.cc:96:
user_prefs::UserPrefs::Get(BrowserStateFromContext(context));
Why is the call to BrowserStateFromContext necessary if UserPrefs::Get now takes
a base::SupportsUserData?

[droger, 2015-04-15 15:33:08]

https://codereview.chromium.org/1062083003/diff/60001/components/keyed_servic...
File components/keyed_service/ios/browser_state_keyed_service_factory.cc
(right):

https://codereview.chromium.org/1062083003/diff/60001/components/keyed_servic...
components/keyed_service/ios/browser_state_keyed_service_factory.cc:96:
user_prefs::UserPrefs::Get(BrowserStateFromContext(context));
On 2015/04/15 15:28:13, Bernhard Bauer wrote:
> Why is the call to BrowserStateFromContext necessary if UserPrefs::Get now
takes
> a base::SupportsUserData?

This is because we currently are in a temporary state where we have both
BrowserContext keyed services and BrowserState keyed services downstream, and
they depend on each other.

We're trying to remove all the BrowserContext references from our downstream
code, but meanwhile we need these hacks.
Eventually we won't need this anymore.

[droger, 2015-04-15 15:37:08]

https://codereview.chromium.org/1062083003/diff/60001/components/keyed_servic...
File components/keyed_service/ios/browser_state_keyed_service_factory.cc
(right):

https://codereview.chromium.org/1062083003/diff/60001/components/keyed_servic...
components/keyed_service/ios/browser_state_keyed_service_factory.cc:96:
user_prefs::UserPrefs::Get(BrowserStateFromContext(context));
On 2015/04/15 15:28:13, Bernhard Bauer wrote:
> Why is the call to BrowserStateFromContext necessary if UserPrefs::Get now
takes
> a base::SupportsUserData?

Also: BrowserStateFromContext() returns base::SupportsUserData.

[Bernhard Bauer, 2015-04-15 15:39:54]

user_prefs LGTM

https://codereview.chromium.org/1062083003/diff/60001/components/keyed_servic...
File components/keyed_service/ios/browser_state_keyed_service_factory.cc
(right):

https://codereview.chromium.org/1062083003/diff/60001/components/keyed_servic...
components/keyed_service/ios/browser_state_keyed_service_factory.cc:96:
user_prefs::UserPrefs::Get(BrowserStateFromContext(context));
On 2015/04/15 15:37:07, droger wrote:
> On 2015/04/15 15:28:13, Bernhard Bauer wrote:
> > Why is the call to BrowserStateFromContext necessary if UserPrefs::Get now
> takes
> > a base::SupportsUserData?
> 
> Also: BrowserStateFromContext() returns base::SupportsUserData.

Yes, that was what confused me :) For the content/ equivalent, it's just a
static cast.

[droger, 2015-04-15 15:40:43]

droger@chromium.org changed reviewers:
+ erg@chromium.org

[droger, 2015-04-15 15:40:44]

+ erg as OWNER of keyed_service

[Elliot Glaysher, 2015-04-15 17:36:13]

lgtm

[droger, 2015-04-15 17:46:04]

Thanks for the reviews.

[droger, 2015-04-15 17:46:13]

The CQ bit was checked by droger@chromium.org

[droger, 2015-04-15 17:46:13]

The patchset sent to the CQ was uploaded after l-g-t-m from
sdefresne@chromium.org, bauerb@chromium.org
Link to the patchset: https://codereview.chromium.org/1062083003/#ps90001
(title: "Add missing include in card_unmask_prompt_controller_impl_unittest.cc")

[commit-bot: I haz the power, 2015-04-15 17:47:46]

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

[commit-bot: I haz the power, 2015-04-15 17:58:01]

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

[commit-bot: I haz the power, 2015-04-15 17:58:02]

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

[droger, 2015-04-16 08:00:01]

droger@chromium.org changed reviewers:
+ estade@chromium.org, rlp@chromium.org

[droger, 2015-04-16 08:00:31]

TBR rlp and estade for missing includes in autofill and spellcheck

[droger, 2015-04-16 08:00:44]

The CQ bit was checked by droger@chromium.org

[commit-bot: I haz the power, 2015-04-16 08:01:09]

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

[commit-bot: I haz the power, 2015-04-16 08:04:40]

Committed patchset #4 (id:90001)

[commit-bot: I haz the power, 2015-04-16 08:05:35]

Patchset 4 (id:??) landed as
https://crrev.com/3b2d62da970372d204fe938da56ee4a662445ba8
Cr-Commit-Position: refs/heads/master@{#325401}