Credential Manager: Renderer-side implementation.

chrome/chrome_common.gypi

Index: chrome/chrome_common.gypi
diff --git a/chrome/chrome_common.gypi b/chrome/chrome_common.gypi
index e41ab38014a467151ffe7816df217c87bb4d47dd..ddf250aba010e1a3faf297dced947710c0d52727 100644
--- a/chrome/chrome_common.gypi
+++ b/chrome/chrome_common.gypi
@@ -369,6 +369,7 @@
             '<(DEPTH)/components/components.gyp:autofill_core_common',
             '<(DEPTH)/components/components.gyp:autofill_content_common',
             '<(DEPTH)/components/components.gyp:password_manager_core_common',

[Ilya Sherman, 2014/08/19 23:55:51]

Hmm, if iOS already doesn't use the password manager, is there any reason to
distinguish between "core" and "content"?

Or, perhaps this line doesn't need to be in the 'OS != "ios"' section?

[vabr (Chromium), 2014/08/20 10:57:47]

Yeah, I actually don't know why all the *_core_common targets are excluded from
iOS (saying that while being responsible for this particular one). Looks like a
good idea to move the *_core_common deps up to the all-including section.

[Mike West, 2014/08/20 13:17:18]

Let's do that in a separate CL? :)

[Mike West, 2014/08/20 13:17:18]

1. Honestly, it's a little bit unclear how we'd go about implementing the API
I'm prototyping in iOS.

2. The message definitions can't be in 'core/common' because they rely on
'content/public/common/common_param_traits.h' for the 'IPC::ParamTraits<GURL>'
definition, and core can't depend on content. :/

[vabr (Chromium), 2014/08/20 14:40:34]

SGTM.

+            '<(DEPTH)/components/components.gyp:password_manager_content_common',
             '<(DEPTH)/components/components.gyp:signin_core_common',
             '<(DEPTH)/components/components.gyp:translate_content_common',
             '<(DEPTH)/components/components.gyp:visitedlink_common',