Extends the CS component to have an API for preferences, with a call
for the Unified Consent use-case.
Extends Contextual Search to record the previous user setting, and use
it for throttling of server requests when needed. Details in
https://go/cs-unity-throttle.
The initial integration with Unified Consent calling this API is in a
separate CL.
Also provides some minor cleanup by adding definitions for the TTS
enabled and disabled setting strings.
BUG=825428
Change-Id: I187e903a30cfb671aeeaba00ce6fb578219c17a2
Reviewed-on: https://chromium-review.googlesource.com/1157869
Commit-Queue: Donn Denman <donnd@chromium.org>
Reviewed-by: Pam Greene (Please send IM for reviews) <pam@chromium.org>
Reviewed-by: Tommy Nyquist <nyquist@chromium.org>
Reviewed-by: Thomas Tangl <tangltom@chromium.org>
Reviewed-by: Theresa <twellington@chromium.org>
Cr-Commit-Position: refs/heads/master@{#585866}
This directory is for features that are intended for reuse. Example use cases:
- features that are shared by Chrome on iOS and other Chrome platforms (since
the iOS port doesn't use src/chrome)
- features that are shared between multiple embedders of content (e.g., Android
WebView and Chrome)
- features that are shared between Blink and the browser process
* Note: It is also possible to place code shared between Blink and the
browser process into //third_party/blink/common. The distinction comes
down to (a) whether Blink is the owner of the code in question or a consumer
of it and (b) whether the code in question is shared by Chrome on iOS as
well. If the code is conceptually its own cross-process feature with Blink
as a consumer, then //components can make sense. If it's conceptually
Blink code, then third_party/blink/common likely makes more sense. (In the
so-far hypothetical case where it's conceptually Blink code that is shared
by iOS, raise the question on chromium-dev@, where the right folks will see
it).
In general, if some code is used by a directory "foo" and things above "foo" in
the dependency tree, the code should probably live in "foo".
By default, components can depend only on the lower layers of the Chromium
codebase (e.g. base/, net/, etc.). Individual components may additionally allow
dependencies on the content API and IPC; however, if such a component is used
by Chrome for iOS (which does not use the content API or IPC), the component
will have to be in the form of a layered component
(http://www.chromium.org/developers/design-documents/layered-components-design).
Components that have bits of code that need to live in different
processes (e.g. some code in the browser process, some in the renderer
process, etc.) should separate the code into different subdirectories.
Hence for a component named 'foo' you might end up with a structure
like the following (assuming that foo is not used by iOS and thus does not
need to be a layered component):
components/foo - DEPS, OWNERS, foo.gypi
components/foo/browser - code that needs the browser process
components/foo/common - for e.g. IPC constants and such
components/foo/renderer - code that needs renderer process
These subdirectories should have DEPS files with the relevant
restrictions in place, i.e. only components/*/browser should
be allowed to #include from content/public/browser.
Note that there may also be an 'android' subdir, with a Java source
code structure underneath it where the package name is
org.chromium.components.foo, and with subdirs after 'foo'
to illustrate process, e.g. 'browser' or 'renderer':
components/foo/android/OWNERS, DEPS
components/foo/android/java/src/org/chromium/components/foo/browser/
components/foo/android/javatests/src/org/chromium/components/foo/browser/
Code in a component should be placed in a namespace corresponding to
the name of the component; e.g. for a component living in
//components/foo, code in that component should be in the foo::
namespace.
b27a1a5d0c