Remove factory methods from ChromeApplication.

Remove factory methods from ChromeApplication.

ChromeApplication currently acts as a provider for singletons where
different behavior is needed for downstream targets. This patch
introduces a new way for upstream and downstream targets to provide
different implementations for the same method.
  * AppHooks.java contains default upstream implementations for all
methods
  * AppHooksImpl.java is the concrete subclass of AppHooks and is
included separately from chrome_java via //chrome/android:app_hooks_java
  * Downstream targets can include their own version of this target
with a different implementation of AppHooksImpl.java

BUG=560466
Review-Url: https://codereview.chromium.org/2697933002
Cr-Commit-Position: refs/heads/master@{#453623}
Committed: https://chromium.googlesource.com/chromium/src/+/6de786cbce94899dc34f457b9c846d54f6f279d5

[estevenson, 2017-02-14 22:19:59]

The CQ bit was checked by estevenson@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-02-14 22:20:46]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-02-14 23:48:18]

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

[commit-bot: I haz the power, 2017-02-14 23:48:19]

Dry run: Try jobs failed on following builders:
  linux_android_rel_ng on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/linux_androi...)

[estevenson, 2017-02-15 15:35:09]

The CQ bit was checked by estevenson@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-02-15 15:35:25]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-02-15 16:40:51]

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

[commit-bot: I haz the power, 2017-02-15 16:40:52]

Dry run: This issue passed the CQ dry run.

[estevenson, 2017-02-15 18:13:54]

Description was changed from

==========
WIP - use new factory class


WIP - build plumbing

BUG=
==========

to

==========
Remove factory methods from ChromeApplication.

ChromeApplication currently acts as a provider for singletons where
different behavior is needed for downstream targets. This patch
introduces a new way for downstream targets to provide their own
implementations:
  * BaseAppGlobals.java contains stub implementations for factory
  methods
  * AppGlobals.java contains implementations, and is included in build
  targets separately from chrome_java via
  //chrome/android:app_globals_java
  * Downstream targets can include their own version of this target with
  a different implementation of AppGlobals.java

BUG=560466
==========

[estevenson, 2017-02-15 18:14:44]

The CQ bit was checked by estevenson@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-02-15 18:15:34]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[estevenson, 2017-02-15 18:26:01]

estevenson@chromium.org changed reviewers:
+ agrieve@chromium.org

[estevenson, 2017-02-15 18:26:02]

ptal Andrew!

What do you think of this approach Andrew? It would require a downstream change
as well of course. 

Assuming we stick with this approach, do you think there's a better way to land
this? My reasoning for adding the build changes and changing all call sites in 1
CL is that it will be cleaner for reverting and only requires 1 downstream CL.

https://codereview.chromium.org/2697933002/diff/40001/chrome/android/java/src...
File chrome/android/java/src/org/chromium/chrome/browser/ChromeApplication.java
(right):

https://codereview.chromium.org/2697933002/diff/40001/chrome/android/java/src...
chrome/android/java/src/org/chromium/chrome/browser/ChromeApplication.java:121:
public void registerPolicyProviders(CombinedPolicyProvider combinedProvider) {
This and checkIsAndroidEduDevice are both overridden downstream but aren't
factory-method-like.. It seems incorrect to add them to a class named
"AppGlobals" but also weird to create another class just for these two methods.
Any ideas?

[agrieve, 2017-02-15 19:18:45]

https://codereview.chromium.org/2697933002/diff/40001/chrome/android/java/src...
File chrome/android/java/src/org/chromium/chrome/browser/AppGlobals.java
(right):

https://codereview.chromium.org/2697933002/diff/40001/chrome/android/java/src...
chrome/android/java/src/org/chromium/chrome/browser/AppGlobals.java:35: * This
class should only contain implementations for methods defined in {@link
BaseAppGlobals}.
nit: can you add a link to the crbug that explains this a bit further.

https://codereview.chromium.org/2697933002/diff/40001/chrome/android/java/src...
File chrome/android/java/src/org/chromium/chrome/browser/BaseAppGlobals.java
(right):

https://codereview.chromium.org/2697933002/diff/40001/chrome/android/java/src...
chrome/android/java/src/org/chromium/chrome/browser/BaseAppGlobals.java:41:
private static class LazyHolder { private static final AppGlobals INSTANCE = new
AppGlobals(); }
nit: I don't think we need the extra class here. Just make it a direct static
field.

https://codereview.chromium.org/2697933002/diff/40001/chrome/android/java/src...
chrome/android/java/src/org/chromium/chrome/browser/BaseAppGlobals.java:43:
public static AppGlobals get() {
Since this is what people call get() on, can you call these classes:
BaseAppGlobals -> AppGlobals
AppGlobals -> AppGlobalsImpl

Calling AppGlobals.get() and having that resolve to BaseAppGlobals.get() is a
java code smell (shouldn't call static methods on subclasses)

https://codereview.chromium.org/2697933002/diff/40001/chrome/android/java/src...
File chrome/android/java/src/org/chromium/chrome/browser/ChromeApplication.java
(right):

https://codereview.chromium.org/2697933002/diff/40001/chrome/android/java/src...
chrome/android/java/src/org/chromium/chrome/browser/ChromeApplication.java:121:
public void registerPolicyProviders(CombinedPolicyProvider combinedProvider) {
On 2017/02/15 18:26:02, estevenson wrote:
> This and checkIsAndroidEduDevice are both overridden downstream but aren't
> factory-method-like.. It seems incorrect to add them to a class named
> "AppGlobals" but also weird to create another class just for these two
methods.
> Any ideas?

Yeah, I agree, I think the thing to do though is to rename the class. Maybe
"DownstreamHooks"? or "DownstreamApi"?

https://codereview.chromium.org/2697933002/diff/40001/chrome/android/java_sou...
File chrome/android/java_sources.gni (right):

https://codereview.chromium.org/2697933002/diff/40001/chrome/android/java_sou...
chrome/android/java_sources.gni:5: app_globals_file =
"java/src/org/chromium/chrome/browser/AppGlobals.java"
nit: I think this would be clearer if you put this in chrome/android/BUILD.gn
since it's used only there.

[agrieve, 2017-02-15 19:19:14]

Also - I think your plan for landing is good. I see no way to not break
downstream, so just keep sheriffs in the loop.

[commit-bot: I haz the power, 2017-02-15 20:12:04]

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

[commit-bot: I haz the power, 2017-02-15 20:12:05]

Dry run: This issue passed the CQ dry run.

[estevenson, 2017-02-15 21:27:45]

Description was changed from

==========
Remove factory methods from ChromeApplication.

ChromeApplication currently acts as a provider for singletons where
different behavior is needed for downstream targets. This patch
introduces a new way for downstream targets to provide their own
implementations:
  * BaseAppGlobals.java contains stub implementations for factory
  methods
  * AppGlobals.java contains implementations, and is included in build
  targets separately from chrome_java via
  //chrome/android:app_globals_java
  * Downstream targets can include their own version of this target with
  a different implementation of AppGlobals.java

BUG=560466
==========

to

==========
Remove factory methods from ChromeApplication.

ChromeApplication currently acts as a provider for singletons where
different behavior is needed for downstream targets. This patch
introduces a new way for upstream and downstream targets to provide different
implementations for the same method.
  * AppHooks.java contains stub implementations for methods
  * AppHooksImpl.java contains implementations, and is included in build
  targets separately from chrome_java via
  //chrome/android:app_hooks_java
  * Downstream targets can include their own version of this target with
  a different implementation of AppHooksImpl.java

BUG=560466
==========

[estevenson, 2017-02-15 21:46:50]

estevenson@chromium.org changed reviewers:
+ tedchoc@chromium.org

[estevenson, 2017-02-15 21:46:51]

ptal Ted!

https://codereview.chromium.org/2697933002/diff/40001/chrome/android/java/src...
File chrome/android/java/src/org/chromium/chrome/browser/AppGlobals.java
(right):

https://codereview.chromium.org/2697933002/diff/40001/chrome/android/java/src...
chrome/android/java/src/org/chromium/chrome/browser/AppGlobals.java:35: * This
class should only contain implementations for methods defined in {@link
BaseAppGlobals}.
On 2017/02/15 19:18:44, agrieve wrote:
> nit: can you add a link to the crbug that explains this a bit further.

Done.

https://codereview.chromium.org/2697933002/diff/40001/chrome/android/java/src...
File chrome/android/java/src/org/chromium/chrome/browser/BaseAppGlobals.java
(right):

https://codereview.chromium.org/2697933002/diff/40001/chrome/android/java/src...
chrome/android/java/src/org/chromium/chrome/browser/BaseAppGlobals.java:41:
private static class LazyHolder { private static final AppGlobals INSTANCE = new
AppGlobals(); }
On 2017/02/15 19:18:44, agrieve wrote:
> nit: I don't think we need the extra class here. Just make it a direct static
> field.

Done.

https://codereview.chromium.org/2697933002/diff/40001/chrome/android/java/src...
chrome/android/java/src/org/chromium/chrome/browser/BaseAppGlobals.java:43:
public static AppGlobals get() {
On 2017/02/15 19:18:44, agrieve wrote:
> Since this is what people call get() on, can you call these classes:
> BaseAppGlobals -> AppGlobals
> AppGlobals -> AppGlobalsImpl
> 
> Calling AppGlobals.get() and having that resolve to BaseAppGlobals.get() is a
> java code smell (shouldn't call static methods on subclasses)

Done.

https://codereview.chromium.org/2697933002/diff/40001/chrome/android/java/src...
File chrome/android/java/src/org/chromium/chrome/browser/ChromeApplication.java
(right):

https://codereview.chromium.org/2697933002/diff/40001/chrome/android/java/src...
chrome/android/java/src/org/chromium/chrome/browser/ChromeApplication.java:121:
public void registerPolicyProviders(CombinedPolicyProvider combinedProvider) {
On 2017/02/15 19:18:44, agrieve wrote:
> On 2017/02/15 18:26:02, estevenson wrote:
> > This and checkIsAndroidEduDevice are both overridden downstream but aren't
> > factory-method-like.. It seems incorrect to add them to a class named
> > "AppGlobals" but also weird to create another class just for these two
> methods.
> > Any ideas?
> 
> Yeah, I agree, I think the thing to do though is to rename the class. Maybe
> "DownstreamHooks"? or "DownstreamApi"?

Done.

https://codereview.chromium.org/2697933002/diff/40001/chrome/android/java_sou...
File chrome/android/java_sources.gni (right):

https://codereview.chromium.org/2697933002/diff/40001/chrome/android/java_sou...
chrome/android/java_sources.gni:5: app_globals_file =
"java/src/org/chromium/chrome/browser/AppGlobals.java"
On 2017/02/15 19:18:44, agrieve wrote:
> nit: I think this would be clearer if you put this in chrome/android/BUILD.gn
> since it's used only there.

Done.

[estevenson, 2017-02-15 22:11:16]

The CQ bit was checked by estevenson@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-02-15 22:12:32]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-02-15 22:37:49]

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

[commit-bot: I haz the power, 2017-02-15 22:37:50]

Dry run: Try jobs failed on following builders:
  win_chromium_x64_rel_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_x64_...)
  win_clang on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_clang/builds/...)

[Ted C, 2017-02-15 23:36:12]

tedchoc@chromium.org changed reviewers:
+ mariakhomenko@chromium.org

[Ted C, 2017-02-15 23:36:13]

+mariakhomenko, there was a parallel effort to solve this, so I'll let her chime
in first.

[Maria, 2017-02-15 23:45:36]

mariakhomenko@chromium.org changed reviewers:
+ cco3@chromium.org

[Maria, 2017-02-15 23:45:37]

Conley has a series of changes to solve the same problem in a different way.
Perhaps it makes sense to have a short meeting for everyone to get on the same
page about this.

[cco3, 2017-02-16 00:14:12]

On 2017/02/15 23:45:37, Maria wrote:
> Conley has a series of changes to solve the same problem in a different way.
> Perhaps it makes sense to have a short meeting for everyone to get on the same
> page about this.

Wow, this is eerily similar to
https://codereview.chromium.org/2677013003/#ps20001

Here's the alternative that doesn't involve any build magic:
https://codereview.chromium.org/2668183002/

[estevenson, 2017-02-16 16:58:19]

The CQ bit was checked by estevenson@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-02-16 16:59:14]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[agrieve, 2017-02-16 17:14:11]

On 2017/02/16 00:14:12, cco3 wrote:
> On 2017/02/15 23:45:37, Maria wrote:
> > Conley has a series of changes to solve the same problem in a different way.
> > Perhaps it makes sense to have a short meeting for everyone to get on the
same
> > page about this.
> 
> Wow, this is eerily similar to
> https://codereview.chromium.org/2677013003/#ps20001
> 
> Here's the alternative that doesn't involve any build magic:
> https://codereview.chromium.org/2668183002/

This lgtm fwiw. 
- The lack of any reflection here makes it work very well with Proguard
optimizations
- The lack of needing cast the application object will make webview happy (as I
understand it)
- It requires no code to run in onCreate, so it will always just work (e.g.
android backups run without an application object)

[cco3, 2017-02-16 18:21:20]

On 2017/02/16 17:14:11, agrieve wrote:
> On 2017/02/16 00:14:12, cco3 wrote:
> > On 2017/02/15 23:45:37, Maria wrote:
> > > Conley has a series of changes to solve the same problem in a different
way.
> > > Perhaps it makes sense to have a short meeting for everyone to get on the
> same
> > > page about this.
> > 
> > Wow, this is eerily similar to
> > https://codereview.chromium.org/2677013003/#ps20001
> > 
> > Here's the alternative that doesn't involve any build magic:
> > https://codereview.chromium.org/2668183002/
> 
> This lgtm fwiw. 
> - The lack of any reflection here makes it work very well with Proguard
> optimizations

Maybe there's an aspect of proguard I'm missing, but won't proguard just strip
out methods?  If there's only one method, isn't that cutting out even more
methods than proguard could?

> - The lack of needing cast the application object will make webview happy (as
I
> understand it)
> - It requires no code to run in onCreate, so it will always just work (e.g.
> android backups run without an application object)

[commit-bot: I haz the power, 2017-02-16 18:59:11]

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

[commit-bot: I haz the power, 2017-02-16 18:59:12]

Dry run: This issue passed the CQ dry run.

[agrieve, 2017-02-16 21:45:49]

On 2017/02/16 18:21:20, cco3 wrote:
> On 2017/02/16 17:14:11, agrieve wrote:
> > On 2017/02/16 00:14:12, cco3 wrote:
> > > On 2017/02/15 23:45:37, Maria wrote:
> > > > Conley has a series of changes to solve the same problem in a different
> way.
> > > > Perhaps it makes sense to have a short meeting for everyone to get on
the
> > same
> > > > page about this.
> > > 
> > > Wow, this is eerily similar to
> > > https://codereview.chromium.org/2677013003/#ps20001
> > > 
> > > Here's the alternative that doesn't involve any build magic:
> > > https://codereview.chromium.org/2668183002/
> > 
> > This lgtm fwiw. 
> > - The lack of any reflection here makes it work very well with Proguard
> > optimizations
> 
> Maybe there's an aspect of proguard I'm missing, but won't proguard just strip
> out methods?  If there's only one method, isn't that cutting out even more
> methods than proguard could?

Proguard is quite good at inlining one-liners, so I don't think this will result
in any actual methods.

Proguard is not good at identifying usages when reflection is involved though.
E.g. Class.newInstance(), I'd guess you'd need to mark all class constructors
used in this way with @UsedByReflection in order to tell proguard not to remove
them.

There are a few downstream-specific methods that are not just returning objects
(e.g.: registerPolicyProviders, checkIsAndroidEduDevice).
There are also some that take parameters (e.g. createExternalDataUseObserver).
Going with a reflection-based approach that returns object means we'd need to
write provider classes just for these helpers.


> 
> > - The lack of needing cast the application object will make webview happy
(as
> I
> > understand it)
> > - It requires no code to run in onCreate, so it will always just work (e.g.
> > android backups run without an application object)

[Torne, 2017-02-17 11:25:21]

torne@chromium.org changed reviewers:
+ torne@chromium.org

[Torne, 2017-02-17 11:25:22]

This looks like a good approach for handling the creation of globals.

https://codereview.chromium.org/2697933002/diff/100001/chrome/android/java/sr...
File chrome/android/java/src/org/chromium/chrome/browser/AppHooksImpl.java
(right):

https://codereview.chromium.org/2697933002/diff/100001/chrome/android/java/sr...
chrome/android/java/src/org/chromium/chrome/browser/AppHooksImpl.java:58: return
new SystemAccountManagerDelegate(ContextUtils.getApplicationContext());
It seems like we might as well just put all these implementations in the base
class and have the "default" AppHooksImpl just be an empty class, unless I'm
missing something.

That seems like it'd also avoid the need for so many two-sided patches when
adding/changing stuff here.

[estevenson, 2017-02-21 17:39:36]

Hi Ted, we've discussed the various approaches offline and plan to move forward
with the approach in this CL (assuming you have no objections). Ptal!

https://codereview.chromium.org/2697933002/diff/100001/chrome/android/java/sr...
File chrome/android/java/src/org/chromium/chrome/browser/AppHooksImpl.java
(right):

https://codereview.chromium.org/2697933002/diff/100001/chrome/android/java/sr...
chrome/android/java/src/org/chromium/chrome/browser/AppHooksImpl.java:58: return
new SystemAccountManagerDelegate(ContextUtils.getApplicationContext());
On 2017/02/17 11:25:22, Torne wrote:
> It seems like we might as well just put all these implementations in the base
> class and have the "default" AppHooksImpl just be an empty class, unless I'm
> missing something.
> 
> That seems like it'd also avoid the need for so many two-sided patches when
> adding/changing stuff here.

I thought it might be a little clearer to have the base class contain stub
implementations but I'm not sure that's correct. Moved implementations to
AppHooks and made AppHooksImpl an empty class.

[Torne, 2017-02-21 17:41:06]

LGTM, thanks for tackling this. This is a great start to get rid of Application
subclasses entirely ;)

[estevenson, 2017-02-21 17:43:19]

Description was changed from

==========
Remove factory methods from ChromeApplication.

ChromeApplication currently acts as a provider for singletons where
different behavior is needed for downstream targets. This patch
introduces a new way for upstream and downstream targets to provide different
implementations for the same method.
  * AppHooks.java contains stub implementations for methods
  * AppHooksImpl.java contains implementations, and is included in build
  targets separately from chrome_java via
  //chrome/android:app_hooks_java
  * Downstream targets can include their own version of this target with
  a different implementation of AppHooksImpl.java

BUG=560466
==========

to

==========
Remove factory methods from ChromeApplication.

ChromeApplication currently acts as a provider for singletons where
different behavior is needed for downstream targets. This patch
introduces a new way for upstream and downstream targets to provide
different implementations for the same method.
  * AppHooks.java contains default upstream implementations for all
methods
  * AppHooksImpl.java is the concrete subclass of AppHooks and is
included separately from chrome_java via //chrome/android:app_hooks_java
  * Downstream targets can include their own version of this target
with a different implementation of AppHooksImpl.java

BUG=560466
==========

[Ted C, 2017-02-27 21:52:04]

lgtm

[estevenson, 2017-02-28 01:55:41]

The CQ bit was checked by estevenson@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-02-28 01:56:24]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[estevenson, 2017-02-28 01:59:20]

Thanks for the reviews! Going to land this tomorrow morning.

[commit-bot: I haz the power, 2017-02-28 03:24:19]

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

[commit-bot: I haz the power, 2017-02-28 03:24:20]

Dry run: This issue passed the CQ dry run.

[estevenson, 2017-02-28 14:58:24]

The CQ bit was checked by estevenson@chromium.org

[estevenson, 2017-02-28 14:58:25]

The patchset sent to the CQ was uploaded after l-g-t-m from
agrieve@chromium.org, torne@chromium.org, tedchoc@chromium.org
Link to the patchset: https://codereview.chromium.org/2697933002/#ps160001
(title: "Rebase + move newly added methods to AppHooks")

[commit-bot: I haz the power, 2017-02-28 14:58:32]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-02-28 15:04:24]

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

[commit-bot: I haz the power, 2017-02-28 15:04:25]

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

[estevenson, 2017-02-28 15:07:52]

The CQ bit was checked by estevenson@chromium.org

[estevenson, 2017-02-28 15:07:53]

The patchset sent to the CQ was uploaded after l-g-t-m from
tedchoc@chromium.org, agrieve@chromium.org, torne@chromium.org
Link to the patchset: https://codereview.chromium.org/2697933002/#ps180001
(title: "Rebase")

[commit-bot: I haz the power, 2017-02-28 15:08:08]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-02-28 16:47:27]

CQ is committing da patch.

Bot data: {"patchset_id": 180001, "attempt_start_ts": 1488294472880890,
"parent_rev": "1476cc6a0abbfe9f9154c398f98335f6b2bd0eaa", "commit_rev":
"6de786cbce94899dc34f457b9c846d54f6f279d5"}

[commit-bot: I haz the power, 2017-02-28 16:48:47]

Description was changed from

==========
Remove factory methods from ChromeApplication.

ChromeApplication currently acts as a provider for singletons where
different behavior is needed for downstream targets. This patch
introduces a new way for upstream and downstream targets to provide
different implementations for the same method.
  * AppHooks.java contains default upstream implementations for all
methods
  * AppHooksImpl.java is the concrete subclass of AppHooks and is
included separately from chrome_java via //chrome/android:app_hooks_java
  * Downstream targets can include their own version of this target
with a different implementation of AppHooksImpl.java

BUG=560466
==========

to

==========
Remove factory methods from ChromeApplication.

ChromeApplication currently acts as a provider for singletons where
different behavior is needed for downstream targets. This patch
introduces a new way for upstream and downstream targets to provide
different implementations for the same method.
  * AppHooks.java contains default upstream implementations for all
methods
  * AppHooksImpl.java is the concrete subclass of AppHooks and is
included separately from chrome_java via //chrome/android:app_hooks_java
  * Downstream targets can include their own version of this target
with a different implementation of AppHooksImpl.java

BUG=560466

Review-Url: https://codereview.chromium.org/2697933002
Cr-Commit-Position: refs/heads/master@{#453623}
Committed:
https://chromium.googlesource.com/chromium/src/+/6de786cbce94899dc34f457b9c84...
==========

[commit-bot: I haz the power, 2017-02-28 16:48:50]

Committed patchset #10 (id:180001) as
https://chromium.googlesource.com/chromium/src/+/6de786cbce94899dc34f457b9c84...