🔍 Move WindowAndroid knowledge up to the base class

🔍 Move WindowAndroid knowledge up to the base class

With half of the direct AsyncInitializationActivity subclasses now
needing knowledge of the WindowAndroid and how to pass things to it
when the Activity requests permission, it makes sense to pull this
up.  Subclasses are still required to instantiate the WindowAndroid
on their own, but the base class will now try to direct things to it
when needed.

Also fixes what seems like a bug where setContentView is called but
onSetContentView isn't.  I don't think the LaunchBehindWorkaround
is needed anymore given that document mode is dead, but I'm not
comfortable with removing it.

BUG=708844
Review-Url: https://codereview.chromium.org/2811093004
Cr-Commit-Position: refs/heads/master@{#464099}
Committed: https://chromium.googlesource.com/chromium/src/+/b7a69bb4cd303a42dc88d7c432db85f570b9d33d

[gone, 2017-04-11 20:43:13]

Description was changed from

==========
🔍 Move WindowAndroid knowledge up to the base class

With half of the direct AsyncInitializationActivity subclasses now
needing knowledge of the WindowAndroid and how to pass things to it when
the Activity requests permission, it makes sense to pull this up.
Subclasses are still required to instantiate the WindowAndroid on their
own, but the base class will now try to direct things to it when needed.

BUG=708844
==========

to

==========
🔍 Move WindowAndroid knowledge up to the base class

With half of the direct AsyncInitializationActivity subclasses now
needing knowledge of the WindowAndroid and how to pass things to it
when the Activity requests permission, it makes sense to pull this
up.  Subclasses are still required to instantiate the WindowAndroid
on their own, but the base class will now try to direct things to it
when needed.

Also fixes what seems like a bug where setContentView is called but
onSetContentView isn't.  I don't think the LaunchBehindWorkaround
is needed anymore given that document mode is dead, but I'm not
comfortable with removing it.

BUG=708844
==========

[gone, 2017-04-11 20:45:11]

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

[gone, 2017-04-11 20:45:26]

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

[commit-bot: I haz the power, 2017-04-11 20:45:53]

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

[Ted C, 2017-04-11 21:07:38]

https://codereview.chromium.org/2811093004/diff/1/chrome/android/java/src/org...
File
chrome/android/java/src/org/chromium/chrome/browser/init/AsyncInitializationActivity.java
(right):

https://codereview.chromium.org/2811093004/diff/1/chrome/android/java/src/org...
chrome/android/java/src/org/chromium/chrome/browser/init/AsyncInitializationActivity.java:420:
protected void setWindowAndroid(ActivityWindowAndroid windowAndroid) {
instead of allowing this to be set, can we make this a (potentially abstract
method if needed) protected ActivityWindowAndroid createWindowAndroid() {...}

I want to get to a state where we are more explicit with our expected ordering
instead of the free for alls that currently exist.

[gone, 2017-04-11 21:32:36]

https://codereview.chromium.org/2811093004/diff/1/chrome/android/java/src/org...
File
chrome/android/java/src/org/chromium/chrome/browser/init/AsyncInitializationActivity.java
(right):

https://codereview.chromium.org/2811093004/diff/1/chrome/android/java/src/org...
chrome/android/java/src/org/chromium/chrome/browser/init/AsyncInitializationActivity.java:420:
protected void setWindowAndroid(ActivityWindowAndroid windowAndroid) {
On 2017/04/11 21:07:38, Ted C wrote:
> instead of allowing this to be set, can we make this a (potentially abstract
> method if needed) protected ActivityWindowAndroid createWindowAndroid() {...}
> 
> I want to get to a state where we are more explicit with our expected ordering
> instead of the free for alls that currently exist.

Yeah, that'd be nice but not all of these child activities currently create a
WindowAndroid.  I've made it a method that's called in a specific place, but
it's
slightly earlier than it used to be.

[Ted C, 2017-04-11 21:49:31]

lgtm

[gone, 2017-04-12 00:48:28]

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

[commit-bot: I haz the power, 2017-04-12 00:49: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-04-12 01:25:20]

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

[commit-bot: I haz the power, 2017-04-12 01:25:21]

Dry run: This issue passed the CQ dry run.

[gone, 2017-04-12 18:19:05]

The CQ bit was checked by dfalcantara@chromium.org

[commit-bot: I haz the power, 2017-04-12 18:19:43]

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-04-12 19:05:17]

CQ is committing da patch.

Bot data: {"patchset_id": 20001, "attempt_start_ts": 1492021145568320,
"parent_rev": "965189d07248dbb0300f0ba4a9eaae6b51ff3d4d", "commit_rev":
"b7a69bb4cd303a42dc88d7c432db85f570b9d33d"}

[commit-bot: I haz the power, 2017-04-12 19:06:12]

Description was changed from

==========
🔍 Move WindowAndroid knowledge up to the base class

With half of the direct AsyncInitializationActivity subclasses now
needing knowledge of the WindowAndroid and how to pass things to it
when the Activity requests permission, it makes sense to pull this
up.  Subclasses are still required to instantiate the WindowAndroid
on their own, but the base class will now try to direct things to it
when needed.

Also fixes what seems like a bug where setContentView is called but
onSetContentView isn't.  I don't think the LaunchBehindWorkaround
is needed anymore given that document mode is dead, but I'm not
comfortable with removing it.

BUG=708844
==========

to

==========
🔍 Move WindowAndroid knowledge up to the base class

With half of the direct AsyncInitializationActivity subclasses now
needing knowledge of the WindowAndroid and how to pass things to it
when the Activity requests permission, it makes sense to pull this
up.  Subclasses are still required to instantiate the WindowAndroid
on their own, but the base class will now try to direct things to it
when needed.

Also fixes what seems like a bug where setContentView is called but
onSetContentView isn't.  I don't think the LaunchBehindWorkaround
is needed anymore given that document mode is dead, but I'm not
comfortable with removing it.

BUG=708844

Review-Url: https://codereview.chromium.org/2811093004
Cr-Commit-Position: refs/heads/master@{#464099}
Committed:
https://chromium.googlesource.com/chromium/src/+/b7a69bb4cd303a42dc88d7c432db...
==========

[commit-bot: I haz the power, 2017-04-12 19:06:14]

Committed patchset #2 (id:20001) as
https://chromium.googlesource.com/chromium/src/+/b7a69bb4cd303a42dc88d7c432db...