Get rid of ToolbarViewResourceFrameLayout

Get rid of ToolbarViewResourceFrameLayout

This layout wraps around the toolbar in the view hierarchy and
the only purpose of it is creating a toolbar specific ResourceAdapter.
This change removes it and makes the parent Toolbar layout handle this
now. Later a new interface will be introduced for texture capture
functionality and pull all related calls out of Toolbar interface.

BUG=507327

[Yusuf, 2015-07-06 17:13:20]

yusufo@chromium.org changed reviewers:
+ dtrainor@chromium.org, tedchoc@chromium.org

[Yusuf, 2015-07-06 17:13:20]

Adding both dtrainor@ and tedchoc@ to make sure both are aware this is
happening.

[David Trainor- moved to gerrit, 2015-07-06 20:54:37]

lgtm

https://codereview.chromium.org/1221333007/diff/1/chrome/android/java/src/org...
File
chrome/android/java/src/org/chromium/chrome/browser/widget/ViewResourceFrameLayout.java
(right):

https://codereview.chromium.org/1221333007/diff/1/chrome/android/java/src/org...
chrome/android/java/src/org/chromium/chrome/browser/widget/ViewResourceFrameLayout.java:22:
private boolean mInitializedForCapture;
Are we sure we want this to default to false?  If so, can we make that clear in
the javadoc for this class?

[Yusuf, 2015-07-06 20:58:22]

https://codereview.chromium.org/1221333007/diff/1/chrome/android/java/src/org...
File
chrome/android/java/src/org/chromium/chrome/browser/widget/ViewResourceFrameLayout.java
(right):

https://codereview.chromium.org/1221333007/diff/1/chrome/android/java/src/org...
chrome/android/java/src/org/chromium/chrome/browser/widget/ViewResourceFrameLayout.java:22:
private boolean mInitializedForCapture;
On 2015/07/06 20:54:37, David Trainor wrote:
> Are we sure we want this to default to false?  If so, can we make that clear
in
> the javadoc for this class?

Good catch. We actually want it to default to true. Only toolbar should be
setting it to false. Will correct that and upload.

[Yusuf, 2015-07-06 23:20:12]

The CQ bit was checked by yusufo@chromium.org

[Yusuf, 2015-07-06 23:20:13]

The patchset sent to the CQ was uploaded after l-g-t-m from
dtrainor@chromium.org
Link to the patchset: https://codereview.chromium.org/1221333007/#ps20001
(title: "Set isInitializedForCapture to true by default and updated javadocs")

[commit-bot: I haz the power, 2015-07-06 23:20:52]

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

[commit-bot: I haz the power, 2015-07-06 23:39:48]

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

[commit-bot: I haz the power, 2015-07-06 23:39:49]

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

(exceeded global retry quota)

[Yusuf, 2015-07-07 00:02:05]

The CQ bit was checked by yusufo@chromium.org

[Yusuf, 2015-07-07 00:02:05]

The patchset sent to the CQ was uploaded after l-g-t-m from
dtrainor@chromium.org
Link to the patchset: https://codereview.chromium.org/1221333007/#ps40001
(title: "Got rid of extra findViewById")

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

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

[commit-bot: I haz the power, 2015-07-07 01:51:34]

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

[commit-bot: I haz the power, 2015-07-07 01:51:35]

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

[Yusuf, 2015-07-16 20:47:45]

The CQ bit was checked by yusufo@chromium.org

[Yusuf, 2015-07-16 20:47:45]

The patchset sent to the CQ was uploaded after l-g-t-m from
dtrainor@chromium.org
Link to the patchset: https://codereview.chromium.org/1221333007/#ps60001
(title: "Lazily initialize resource adapter")

[commit-bot: I haz the power, 2015-07-16 20:50:29]

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

[commit-bot: I haz the power, 2015-07-16 23:20:36]

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

[commit-bot: I haz the power, 2015-07-16 23:20:37]

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

[Yusuf, 2015-07-17 20:38:59]

The CQ bit was checked by yusufo@chromium.org

[commit-bot: I haz the power, 2015-07-17 20:39:16]

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

[commit-bot: I haz the power, 2015-07-17 22:33:52]

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

[commit-bot: I haz the power, 2015-07-17 22:33:54]

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

[Yusuf, 2015-07-20 19:09:18]

PTAL again with the new update:

Lazy initialization didn't cut it, since we end up calling this pretty early on.
Switched to sending the ToolbarLayout as the container rather than
ControlContainer. This tight coupling between ControlContainer and ToolbarLayout
is one of the reasons I am doing this refactoring. Initialization time calls
like this makes it impossible to construct these two classes independently.


Since ToolbarLayout always matches to parent in both dimensions, this gives the
same results in all related calls.

[David Trainor- moved to gerrit, 2015-07-20 21:16:37]

Is this okay on tablets too?  If so, lgtm.