RenderWidget/RenderView: encapsulate ViewHostMsg_Show, etc, in a callback

RenderWidget/RenderView: Introduce a callback into the opener RenderViewHost,
that is executed at WebWidgetClient::show() time.  This callback fully replaces
the |opener_id_| and |opened_by_user_gesture_| data members.

Ultimately, there are three variants of ShowCallback: one each to send
ViewHostMsg_ShowWidget, ViewHostMsg_ShowFullscreenWidget, and
ViewHostMsg_ShowView. Encapsulating these in a callback will make it possible to
port these messages from RenderView to RenderFrame independently, without
further complexity in RenderWidget.

This rearrangement also has the benefit of making the Send() happen on the
object that the message is actually routed by. That should help with later
mojofication.

Remove RenderWidgetFullscreen, which contained no real code after
moving the body of ::show() into the callback. Instead, have
RenderWidgetFullscreenPepper (its only subclass) directly derive from
RenderWidget.

Android Webview's HandleNavigation path had an odd dependency on
|opener_id_| that does not look correct. I've tried to preserve
its behavior with this CL, since this path is deprecated.

BUG=627852
Committed: https://crrev.com/f7b382233d382060eb1b352aa1ea9dffc36a9e44
Cr-Commit-Position: refs/heads/master@{#433999}

[ncarter (slow), 2016-11-10 23:47:18]

Description was changed from

==========
RenderWidget/RenderView: replace opener_id_ and opened_by_user_gesture_
with a callback into the opener RenderViewHost, that is executed at
WebWidgetClient::show() time.

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

to

==========
RenderWidget/RenderView: replace opener_id_ and opened_by_user_gesture_
with a callback into the opener RenderViewHost, that is executed at
WebWidgetClient::show() time.

Eliminating opener_id_ will make it possible to do porting of
ViewHostMsg_ShowWidget/ViewHostMsg_ShowFullscreenWidget/ViewHostMsg_ShowView
independently, and without additional changes to RenderWidget.

This has the effect of actually doing a Send() of the
ViewHostMsg_ShowWidget/ShowFullscreenWidget/ViewHostMsg_ShowView from the object
that the message is routed on. That should make subsequent mojofication easier.

BUG=627852
==========

[ncarter (slow), 2016-11-10 23:50:28]

Description was changed from

==========
RenderWidget/RenderView: replace opener_id_ and opened_by_user_gesture_
with a callback into the opener RenderViewHost, that is executed at
WebWidgetClient::show() time.

Eliminating opener_id_ will make it possible to do porting of
ViewHostMsg_ShowWidget/ViewHostMsg_ShowFullscreenWidget/ViewHostMsg_ShowView
independently, and without additional changes to RenderWidget.

This has the effect of actually doing a Send() of the
ViewHostMsg_ShowWidget/ShowFullscreenWidget/ViewHostMsg_ShowView from the object
that the message is routed on. That should make subsequent mojofication easier.

BUG=627852
==========

to

==========
RenderWidget/RenderView: replace opener_id_ and opened_by_user_gesture_
with a callback into the opener RenderViewHost, that is executed at
WebWidgetClient::show() time.

Eliminating opener_id_ will make it possible to do porting of
ViewHostMsg_ShowWidget/ViewHostMsg_ShowFullscreenWidget/ViewHostMsg_ShowView
independently, and without additional changes to RenderWidget.

Using a callback also has the benefit of actually doing a Send() of the
ViewHostMsg_ShowWidget/ShowFullscreenWidget/ViewHostMsg_ShowView from the object
that the message is routed on. That should ease later mojofication.

Eliminating opener_id_ also lets us remove an out-param from the signature of
RenderFrameImpl::ResolveOpener, which only existed to populate that field.

BUG=627852
==========

[ncarter (slow), 2016-11-10 23:51:50]

Description was changed from

==========
RenderWidget/RenderView: replace opener_id_ and opened_by_user_gesture_
with a callback into the opener RenderViewHost, that is executed at
WebWidgetClient::show() time.

Eliminating opener_id_ will make it possible to do porting of
ViewHostMsg_ShowWidget/ViewHostMsg_ShowFullscreenWidget/ViewHostMsg_ShowView
independently, and without additional changes to RenderWidget.

Using a callback also has the benefit of actually doing a Send() of the
ViewHostMsg_ShowWidget/ShowFullscreenWidget/ViewHostMsg_ShowView from the object
that the message is routed on. That should ease later mojofication.

Eliminating opener_id_ also lets us remove an out-param from the signature of
RenderFrameImpl::ResolveOpener, which only existed to populate that field.

BUG=627852
==========

to

==========
RenderWidget/RenderView: replace opener_id_ and opened_by_user_gesture_
with a callback into the opener RenderViewHost, that is executed at
WebWidgetClient::show() time.

Eliminating opener_id_ will make it possible to do porting of
ViewHostMsg_ShowWidget/ViewHostMsg_ShowFullscreenWidget/ViewHostMsg_ShowView
independently, and without additional changes to RenderWidget.

Using a callback also has the benefit of actually doing a Send() of the
ViewHostMsg_ShowWidget/ViewHostMsg_ShowFullscreenWidget/ViewHostMsg_ShowView
from the object that the message is routed on. That should ease later
mojofication.

Eliminating opener_id_ also lets us remove an out-param from the signature of
RenderFrameImpl::ResolveOpener, which only existed to populate that field.

BUG=627852
==========

[ncarter (slow), 2016-11-10 23:57:28]

Description was changed from

==========
RenderWidget/RenderView: replace opener_id_ and opened_by_user_gesture_
with a callback into the opener RenderViewHost, that is executed at
WebWidgetClient::show() time.

Eliminating opener_id_ will make it possible to do porting of
ViewHostMsg_ShowWidget/ViewHostMsg_ShowFullscreenWidget/ViewHostMsg_ShowView
independently, and without additional changes to RenderWidget.

Using a callback also has the benefit of actually doing a Send() of the
ViewHostMsg_ShowWidget/ViewHostMsg_ShowFullscreenWidget/ViewHostMsg_ShowView
from the object that the message is routed on. That should ease later
mojofication.

Eliminating opener_id_ also lets us remove an out-param from the signature of
RenderFrameImpl::ResolveOpener, which only existed to populate that field.

BUG=627852
==========

to

==========
RenderWidget/RenderView: replace opener_id_ and opened_by_user_gesture_
with a callback into the opener RenderViewHost, that is executed at
WebWidgetClient::show() time.

Ultimately, this callback takes on three non-null values: one each to send
ViewHostMsg_ShowWidget, ViewHostMsg_ShowFullscreenWidget, ViewHostMsg_ShowView
Eliminating opener_id_ will make it possible to port these messages from
RenderView to RenderFrame independently, without additional complexity in
RenderWidget.

This rearrangement also has the benefit of making the Send() happen on the
object that the message is actually routed by. That should help with later
mojofication.

Eliminating opener_id_ also lets us remove an out-param from the signature of
RenderFrameImpl::ResolveOpener, which only existed to populate that field. This
makes call sites of RenderFrameImpl::ResolveOpener much cleaner, and fixes a
TODO.

BUG=627852
==========

[ncarter (slow), 2016-11-10 23:58:23]

Description was changed from

==========
RenderWidget/RenderView: replace opener_id_ and opened_by_user_gesture_
with a callback into the opener RenderViewHost, that is executed at
WebWidgetClient::show() time.

Ultimately, this callback takes on three non-null values: one each to send
ViewHostMsg_ShowWidget, ViewHostMsg_ShowFullscreenWidget, ViewHostMsg_ShowView
Eliminating opener_id_ will make it possible to port these messages from
RenderView to RenderFrame independently, without additional complexity in
RenderWidget.

This rearrangement also has the benefit of making the Send() happen on the
object that the message is actually routed by. That should help with later
mojofication.

Eliminating opener_id_ also lets us remove an out-param from the signature of
RenderFrameImpl::ResolveOpener, which only existed to populate that field. This
makes call sites of RenderFrameImpl::ResolveOpener much cleaner, and fixes a
TODO.

BUG=627852
==========

to

==========
RenderWidget/RenderView: replace opener_id_ and opened_by_user_gesture_
with a callback into the opener RenderViewHost, that is executed at
WebWidgetClient::show() time.

Ultimately, this callback takes on three non-null values: one each to send
ViewHostMsg_ShowWidget, ViewHostMsg_ShowFullscreenWidget, and
ViewHostMsg_ShowView. Eliminating opener_id_ will make it possible to port these
messages from RenderView to RenderFrame independently, without adding additional
complexity to RenderWidget.

This rearrangement also has the benefit of making the Send() happen on the
object that the message is actually routed by. That should help with later
mojofication.

Eliminating opener_id_ also lets us remove an out-param from the signature of
RenderFrameImpl::ResolveOpener, which only existed to populate that field. This
makes call sites of RenderFrameImpl::ResolveOpener much cleaner, and fixes a
TODO.

BUG=627852
==========

[ncarter (slow), 2016-11-11 00:01:00]

Description was changed from

==========
RenderWidget/RenderView: replace opener_id_ and opened_by_user_gesture_
with a callback into the opener RenderViewHost, that is executed at
WebWidgetClient::show() time.

Ultimately, this callback takes on three non-null values: one each to send
ViewHostMsg_ShowWidget, ViewHostMsg_ShowFullscreenWidget, and
ViewHostMsg_ShowView. Eliminating opener_id_ will make it possible to port these
messages from RenderView to RenderFrame independently, without adding additional
complexity to RenderWidget.

This rearrangement also has the benefit of making the Send() happen on the
object that the message is actually routed by. That should help with later
mojofication.

Eliminating opener_id_ also lets us remove an out-param from the signature of
RenderFrameImpl::ResolveOpener, which only existed to populate that field. This
makes call sites of RenderFrameImpl::ResolveOpener much cleaner, and fixes a
TODO.

BUG=627852
==========

to

==========
RenderWidget/RenderView: Introduce a callback into the opener RenderViewHost,
that is executed at WebWidgetClient::show() time.  This callback fully replaces
the |opener_id_| and |opened_by_user_gesture_| data members.

Ultimately, there are three variants of ShowCallback: one each to send
ViewHostMsg_ShowWidget, ViewHostMsg_ShowFullscreenWidget, and
ViewHostMsg_ShowView. Encapsulating these in a callback will make it possible to
port these messages from RenderView to RenderFrame independently, without 
further complexity in RenderWidget.

This rearrangement also has the benefit of making the Send() happen on the
object that the message is actually routed by. That should help with later
mojofication.

Eliminating opener_id_ also lets us remove an out-param from the signature of
RenderFrameImpl::ResolveOpener, which only existed to populate that field. This
makes call sites of RenderFrameImpl::ResolveOpener much cleaner, and fixes a
TODO.

BUG=627852
==========

[ncarter (slow), 2016-11-11 00:01:23]

Description was changed from

==========
RenderWidget/RenderView: Introduce a callback into the opener RenderViewHost,
that is executed at WebWidgetClient::show() time.  This callback fully replaces
the |opener_id_| and |opened_by_user_gesture_| data members.

Ultimately, there are three variants of ShowCallback: one each to send
ViewHostMsg_ShowWidget, ViewHostMsg_ShowFullscreenWidget, and
ViewHostMsg_ShowView. Encapsulating these in a callback will make it possible to
port these messages from RenderView to RenderFrame independently, without 
further complexity in RenderWidget.

This rearrangement also has the benefit of making the Send() happen on the
object that the message is actually routed by. That should help with later
mojofication.

Eliminating opener_id_ also lets us remove an out-param from the signature of
RenderFrameImpl::ResolveOpener, which only existed to populate that field. This
makes call sites of RenderFrameImpl::ResolveOpener much cleaner, and fixes a
TODO.

BUG=627852
==========

to

==========
RenderWidget/RenderView: Introduce a callback into the opener RenderViewHost,
that is executed at WebWidgetClient::show() time.  This callback fully replaces
the |opener_id_| and |opened_by_user_gesture_| data members.

Ultimately, there are three variants of ShowCallback: one each to send
ViewHostMsg_ShowWidget, ViewHostMsg_ShowFullscreenWidget, and
ViewHostMsg_ShowView. Encapsulating these in a callback will make it possible to
port these messages from RenderView to RenderFrame independently, without 
further complexity in RenderWidget.

This rearrangement also has the benefit of making the Send() happen on the
object that the message is actually routed by. That should help with later
mojofication.

Eliminating |opener_id_| also lets us remove an out-param from the signature of
RenderFrameImpl::ResolveOpener, which only existed to populate that field. This
makes call sites of RenderFrameImpl::ResolveOpener much cleaner, and fixes a
TODO.

BUG=627852
==========

[ncarter (slow), 2016-11-11 00:01:34]

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

[commit-bot: I haz the power, 2016-11-11 00:02:50]

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

[ncarter (slow), 2016-11-11 00:09:41]

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

[commit-bot: I haz the power, 2016-11-11 00:10:15]

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

[ncarter (slow), 2016-11-11 00:11:07]

nick@chromium.org changed reviewers:
+ alexmos@chromium.org

[ncarter (slow), 2016-11-11 00:11:07]

Hi Alex, please review

[commit-bot: I haz the power, 2016-11-11 00:33:12]

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

[commit-bot: I haz the power, 2016-11-11 00:33:13]

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

[ncarter (slow), 2016-11-11 05:59:11]

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

[commit-bot: I haz the power, 2016-11-11 05:59:25]

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

[ncarter (slow), 2016-11-11 06:00:56]

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

[commit-bot: I haz the power, 2016-11-11 06:01:00]

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, 2016-11-11 06:02:56]

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

[commit-bot: I haz the power, 2016-11-11 06:02:57]

Dry run: Try jobs failed on following builders:
  ios-device on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-device/builds...)
  mac_chromium_compile_dbg_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)

[ncarter (slow), 2016-11-11 16:30:13]

This is witnessing patch failure because its dependent patchset got reverted due
to DCHECKs

[ncarter (slow), 2016-11-14 21:16:16]

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

[commit-bot: I haz the power, 2016-11-14 21:17:54]

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, 2016-11-14 21:26:54]

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

[commit-bot: I haz the power, 2016-11-14 21:26:55]

Dry run: Try jobs failed on following builders:
  ios-simulator on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-simulator/bui...)

[ncarter (slow), 2016-11-14 23:47:04]

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

[commit-bot: I haz the power, 2016-11-14 23:48: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, 2016-11-14 23:54:55]

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

[commit-bot: I haz the power, 2016-11-14 23:54:56]

Dry run: Try jobs failed on following builders:
  ios-device on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-device/builds...)
  ios-simulator on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-simulator/bui...)
  mac_chromium_compile_dbg_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)
  mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[ncarter (slow), 2016-11-15 00:32:38]

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

[commit-bot: I haz the power, 2016-11-15 00:33:48]

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, 2016-11-15 01:39:42]

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

[commit-bot: I haz the power, 2016-11-15 01:39:42]

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

[ncarter (slow), 2016-11-15 23:44:03]

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

[ncarter (slow), 2016-11-15 23:44:45]

Description was changed from

==========
RenderWidget/RenderView: Introduce a callback into the opener RenderViewHost,
that is executed at WebWidgetClient::show() time.  This callback fully replaces
the |opener_id_| and |opened_by_user_gesture_| data members.

Ultimately, there are three variants of ShowCallback: one each to send
ViewHostMsg_ShowWidget, ViewHostMsg_ShowFullscreenWidget, and
ViewHostMsg_ShowView. Encapsulating these in a callback will make it possible to
port these messages from RenderView to RenderFrame independently, without 
further complexity in RenderWidget.

This rearrangement also has the benefit of making the Send() happen on the
object that the message is actually routed by. That should help with later
mojofication.

Eliminating |opener_id_| also lets us remove an out-param from the signature of
RenderFrameImpl::ResolveOpener, which only existed to populate that field. This
makes call sites of RenderFrameImpl::ResolveOpener much cleaner, and fixes a
TODO.

BUG=627852
==========

to

==========
RenderWidget/RenderView: Introduce a callback into the opener RenderViewHost,
that is executed at WebWidgetClient::show() time.  This callback fully replaces
the |opener_id_| and |opened_by_user_gesture_| data members.

Ultimately, there are three variants of ShowCallback: one each to send
ViewHostMsg_ShowWidget, ViewHostMsg_ShowFullscreenWidget, and
ViewHostMsg_ShowView. Encapsulating these in a callback will make it possible to
port these messages from RenderView to RenderFrame independently, without 
further complexity in RenderWidget.

This rearrangement also has the benefit of making the Send() happen on the
object that the message is actually routed by. That should help with later
mojofication.

BUG=627852
==========

[commit-bot: I haz the power, 2016-11-15 23:44:45]

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

[ncarter (slow), 2016-11-15 23:44:57]

nick@chromium.org changed reviewers:
+ lfg@chromium.org
- alexmos@chromium.org

[ncarter (slow), 2016-11-16 00:38:26]

Description was changed from

==========
RenderWidget/RenderView: Introduce a callback into the opener RenderViewHost,
that is executed at WebWidgetClient::show() time.  This callback fully replaces
the |opener_id_| and |opened_by_user_gesture_| data members.

Ultimately, there are three variants of ShowCallback: one each to send
ViewHostMsg_ShowWidget, ViewHostMsg_ShowFullscreenWidget, and
ViewHostMsg_ShowView. Encapsulating these in a callback will make it possible to
port these messages from RenderView to RenderFrame independently, without 
further complexity in RenderWidget.

This rearrangement also has the benefit of making the Send() happen on the
object that the message is actually routed by. That should help with later
mojofication.

BUG=627852
==========

to

==========
RenderWidget/RenderView: Introduce a callback into the opener RenderViewHost,
that is executed at WebWidgetClient::show() time.  This callback fully replaces
the |opener_id_| and |opened_by_user_gesture_| data members.

Ultimately, there are three variants of ShowCallback: one each to send
ViewHostMsg_ShowWidget, ViewHostMsg_ShowFullscreenWidget, and
ViewHostMsg_ShowView. Encapsulating these in a callback will make it possible to
port these messages from RenderView to RenderFrame independently, without 
further complexity in RenderWidget.

This rearrangement also has the benefit of making the Send() happen on the
object that the message is actually routed by. That should help with later
mojofication.

Remove RenderWidgetFullscreen, which contained almost no code after removing
::send().

BUG=627852
==========

[ncarter (slow), 2016-11-16 00:38:37]

Description was changed from

==========
RenderWidget/RenderView: Introduce a callback into the opener RenderViewHost,
that is executed at WebWidgetClient::show() time.  This callback fully replaces
the |opener_id_| and |opened_by_user_gesture_| data members.

Ultimately, there are three variants of ShowCallback: one each to send
ViewHostMsg_ShowWidget, ViewHostMsg_ShowFullscreenWidget, and
ViewHostMsg_ShowView. Encapsulating these in a callback will make it possible to
port these messages from RenderView to RenderFrame independently, without 
further complexity in RenderWidget.

This rearrangement also has the benefit of making the Send() happen on the
object that the message is actually routed by. That should help with later
mojofication.

Remove RenderWidgetFullscreen, which contained almost no code after removing
::send().

BUG=627852
==========

to

==========
RenderWidget/RenderView: Introduce a callback into the opener RenderViewHost,
that is executed at WebWidgetClient::show() time.  This callback fully replaces
the |opener_id_| and |opened_by_user_gesture_| data members.

Ultimately, there are three variants of ShowCallback: one each to send
ViewHostMsg_ShowWidget, ViewHostMsg_ShowFullscreenWidget, and
ViewHostMsg_ShowView. Encapsulating these in a callback will make it possible to
port these messages from RenderView to RenderFrame independently, without 
further complexity in RenderWidget.

This rearrangement also has the benefit of making the Send() happen on the
object that the message is actually routed by. That should help with later
mojofication.

Remove RenderWidgetFullscreen, which contained almost no code after removing
::show().

BUG=627852
==========

[ncarter (slow), 2016-11-16 00:39:02]

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

[commit-bot: I haz the power, 2016-11-16 00:39:34]

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, 2016-11-16 01:28:29]

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

[commit-bot: I haz the power, 2016-11-16 01:28:31]

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

[ncarter (slow), 2016-11-16 17:37:34]

nick@chromium.org changed reviewers:
+ alexmos@chromium.org

[ncarter (slow), 2016-11-16 17:37:35]

Lucas & Alex: please review

[ncarter (slow), 2016-11-16 17:39:50]

Description was changed from

==========
RenderWidget/RenderView: Introduce a callback into the opener RenderViewHost,
that is executed at WebWidgetClient::show() time.  This callback fully replaces
the |opener_id_| and |opened_by_user_gesture_| data members.

Ultimately, there are three variants of ShowCallback: one each to send
ViewHostMsg_ShowWidget, ViewHostMsg_ShowFullscreenWidget, and
ViewHostMsg_ShowView. Encapsulating these in a callback will make it possible to
port these messages from RenderView to RenderFrame independently, without 
further complexity in RenderWidget.

This rearrangement also has the benefit of making the Send() happen on the
object that the message is actually routed by. That should help with later
mojofication.

Remove RenderWidgetFullscreen, which contained almost no code after removing
::show().

BUG=627852
==========

to

==========
RenderWidget/RenderView: Introduce a callback into the opener RenderViewHost,
that is executed at WebWidgetClient::show() time.  This callback fully replaces
the |opener_id_| and |opened_by_user_gesture_| data members.

Ultimately, there are three variants of ShowCallback: one each to send
ViewHostMsg_ShowWidget, ViewHostMsg_ShowFullscreenWidget, and
ViewHostMsg_ShowView. Encapsulating these in a callback will make it possible to
port these messages from RenderView to RenderFrame independently, without 
further complexity in RenderWidget.

This rearrangement also has the benefit of making the Send() happen on the
object that the message is actually routed by. That should help with later
mojofication.

Remove RenderWidgetFullscreen, which contained no real code after
moving the body of ::show() into the callback. Instead, have
RenderWidgetFullscreenPepper (its only subclass) directly derive from
RenderWidget.

Android Webview's HandleNavigation path had an odd dependency on
|opener_id_| that does not look correct. I've tried to preserve
its behavior with this CL, since this path is deprecated.

BUG=627852
==========

[lfg, 2016-11-16 23:07:58]

Just one question.

https://codereview.chromium.org/2498463002/diff/200001/content/renderer/rende...
File content/renderer/render_frame_impl.cc (right):

https://codereview.chromium.org/2498463002/diff/200001/content/renderer/rende...
content/renderer/render_frame_impl.cc:1362:
widget->show(blink::WebNavigationPolicyIgnore);
Do you need the callback here? show() is called immediately after, maybe we can
just call ShowCreatedFullscreenWidget here?

[ncarter (slow), 2016-11-16 23:14:09]

https://codereview.chromium.org/2498463002/diff/200001/content/renderer/rende...
File content/renderer/render_frame_impl.cc (right):

https://codereview.chromium.org/2498463002/diff/200001/content/renderer/rende...
content/renderer/render_frame_impl.cc:1362:
widget->show(blink::WebNavigationPolicyIgnore);
On 2016/11/16 23:07:58, lfg wrote:
> Do you need the callback here? show() is called immediately after, maybe we
can
> just call ShowCreatedFullscreenWidget here?

That occurred to me too (though I'm looking at this CL with fresh eyes after
hearing your reaction to the ShowCallback).

I didn't try it, because I was worried about losing the other side effects of
show(): setting did_show_ to true, and the SetPendingWindowRect() operation
(which, I think, sets up an expectation for the Move ACK that's sent in response
to the show operation).

I'll leave a TODO here to consider simplifying this when migrating
ShowCreatedFullscreenWidget to RenderFrame.

[alexmos, 2016-11-17 09:51:09]

Nice!  Mostly nits below.

https://codereview.chromium.org/2498463002/diff/200001/android_webview/render...
File android_webview/renderer/aw_content_renderer_client.cc (right):

https://codereview.chromium.org/2498463002/diff/200001/android_webview/render...
android_webview/renderer/aw_content_renderer_client.cc:131: // be deferred until
after the java side has been constructed.
Do you understand this comment?  I can't tell why this would imply the need for
the opener check and the return false.

https://codereview.chromium.org/2498463002/diff/200001/android_webview/render...
android_webview/renderer/aw_content_renderer_client.cc:139: if
(render_view_was_created_with_opener) {
You could also name this render_view_was_created_by_renderer.  I'm split about
which is better -- the created_by_renderer conveys its actual meaning better
(now that opener_id_ is gone) but the current name better matches old behavior. 
(Then again, I don't understand the reason for that behavior and the comment
above).

https://codereview.chromium.org/2498463002/diff/200001/content/renderer/rende...
File content/renderer/render_view_impl.cc (right):

https://codereview.chromium.org/2498463002/diff/200001/content/renderer/rende...
content/renderer/render_view_impl.cc:808: // If this is a popup, we won't be
visible until we ask our opener (via
nit: is it really correct to say "If this is a popup", since we need to call
show_callback in all the renderer-initiated cases, including fullscreen widgets
which aren't popups?  Perhaps enumerate the three cases that need this?

https://codereview.chromium.org/2498463002/diff/200001/content/renderer/rende...
content/renderer/render_view_impl.cc:1949: // that was created via
RenderViewImpl::CreateWebView.  So, we wait until this
Perhaps update this while you're here?

https://codereview.chromium.org/2498463002/diff/200001/content/renderer/rende...
content/renderer/render_view_impl.cc:1956: if (did_show_ &&
!webkit_preferences_.supports_multiple_windows) {
Just to confirm, the NOTREACHED is gone because if we get here with did_show_
and supports_multiple_windows both being true, we'll hit the DCHECK in
RenderWidget::show instead?

https://codereview.chromium.org/2498463002/diff/200001/content/renderer/rende...
File content/renderer/render_view_impl.h (right):

https://codereview.chromium.org/2498463002/diff/200001/content/renderer/rende...
content/renderer/render_view_impl.h:844: // Whether this was a renderer-created
or browser-created webview.
nit: webview -> view or RenderView

https://codereview.chromium.org/2498463002/diff/200001/content/renderer/rende...
File content/renderer/render_widget.h (left):

https://codereview.chromium.org/2498463002/diff/200001/content/renderer/rende...
content/renderer/render_widget.h:631: int32_t opener_id_;
Hooray!  Glad to see it gone.

https://codereview.chromium.org/2498463002/diff/200001/content/renderer/rende...
File content/renderer/render_widget_fullscreen_pepper.h (right):

https://codereview.chromium.org/2498463002/diff/200001/content/renderer/rende...
content/renderer/render_widget_fullscreen_pepper.h:26: class RenderFrameImpl;
where is this needed?

[lfg, 2016-11-17 16:37:29]

The things I like about this CL is removing the opener_id, removing/simplifying
fullscreen, making the IPCs go through the more correct routing id and making it
obvious that we have 4 types of widgets: views, popups, fullscreen and frames,
as well as making it explicit that frames don't get the show callback.

The thing that I don't like is that the callback is a bit harder to follow, and
storing the callback as a member of the RenderWidget to be called only once
doesn't look very nice.

However, I think that this should work just fine and that we are moving in the
right direction, so lgtm.

https://codereview.chromium.org/2498463002/diff/200001/content/renderer/rende...
File content/renderer/render_frame_impl.cc (right):

https://codereview.chromium.org/2498463002/diff/200001/content/renderer/rende...
content/renderer/render_frame_impl.cc:1362:
widget->show(blink::WebNavigationPolicyIgnore);
On 2016/11/16 23:14:08, ncarter wrote:
> On 2016/11/16 23:07:58, lfg wrote:
> > Do you need the callback here? show() is called immediately after, maybe we
> can
> > just call ShowCreatedFullscreenWidget here?
> 
> That occurred to me too (though I'm looking at this CL with fresh eyes after
> hearing your reaction to the ShowCallback).
> 
> I didn't try it, because I was worried about losing the other side effects of
> show(): setting did_show_ to true, and the SetPendingWindowRect() operation
> (which, I think, sets up an expectation for the Move ACK that's sent in
response
> to the show operation).
> 
> I'll leave a TODO here to consider simplifying this when migrating
> ShowCreatedFullscreenWidget to RenderFrame.

Acknowledged.

[ncarter (slow), 2016-11-17 19:21:21]

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

[commit-bot: I haz the power, 2016-11-17 19:22:23]

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

[ncarter (slow), 2016-11-17 19:33:11]

https://codereview.chromium.org/2498463002/diff/200001/android_webview/render...
File android_webview/renderer/aw_content_renderer_client.cc (right):

https://codereview.chromium.org/2498463002/diff/200001/android_webview/render...
android_webview/renderer/aw_content_renderer_client.cc:131: // be deferred until
after the java side has been constructed.
On 2016/11/17 09:51:09, alexmos wrote:
> Do you understand this comment?  I can't tell why this would imply the need
for
> the opener check and the return false. 

I interpret this comment to mean: "when a new WebContents is created, there's a
built-in chance to hook its initial navigation on the java/browser side, e.g.
because such creation goes through AwWebContentsDelegate.java or something
similar." I don't know what java code is actually being referenced.

This reasoning seems incorrect for subsequent navigations; my goal with these
edits was to not disturb the existing behavior, and to maybe draw attention to
this potential bug. I know there's a long term plan to eliminate this method, so
preserving weird behavior seems like a reasonable course here, so long as it's
not insecure. I get the sense that Android Webview has some pretty serious
reverse-compatibility constraints.

I am looping sgurun into this CL for the android webview perspective.

https://codereview.chromium.org/2498463002/diff/200001/android_webview/render...
android_webview/renderer/aw_content_renderer_client.cc:139: if
(render_view_was_created_with_opener) {
On 2016/11/17 09:51:09, alexmos wrote:
> You could also name this render_view_was_created_by_renderer.  I'm split about
> which is better -- the created_by_renderer conveys its actual meaning better
> (now that opener_id_ is gone) but the current name better matches old
behavior. 
> (Then again, I don't understand the reason for that behavior and the comment
> above).

render_view_was_created_by_renderer is a better more consistent name. Done.

https://codereview.chromium.org/2498463002/diff/200001/content/renderer/rende...
File content/renderer/render_frame_impl.cc (right):

https://codereview.chromium.org/2498463002/diff/200001/content/renderer/rende...
content/renderer/render_frame_impl.cc:1362:
widget->show(blink::WebNavigationPolicyIgnore);
On 2016/11/17 16:37:29, lfg wrote:
> On 2016/11/16 23:14:08, ncarter wrote:
> > On 2016/11/16 23:07:58, lfg wrote:
> > > Do you need the callback here? show() is called immediately after, maybe
we
> > can
> > > just call ShowCreatedFullscreenWidget here?
> > 
> > That occurred to me too (though I'm looking at this CL with fresh eyes after
> > hearing your reaction to the ShowCallback).
> > 
> > I didn't try it, because I was worried about losing the other side effects
of
> > show(): setting did_show_ to true, and the SetPendingWindowRect() operation
> > (which, I think, sets up an expectation for the Move ACK that's sent in
> response
> > to the show operation).
> > 
> > I'll leave a TODO here to consider simplifying this when migrating
> > ShowCreatedFullscreenWidget to RenderFrame.
> 
> Acknowledged.

Comment added.

https://codereview.chromium.org/2498463002/diff/200001/content/renderer/rende...
File content/renderer/render_view_impl.cc (right):

https://codereview.chromium.org/2498463002/diff/200001/content/renderer/rende...
content/renderer/render_view_impl.cc:808: // If this is a popup, we won't be
visible until we ask our opener (via
On 2016/11/17 09:51:09, alexmos wrote:
> nit: is it really correct to say "If this is a popup", since we need to call
> show_callback in all the renderer-initiated cases, including fullscreen
widgets
> which aren't popups?  Perhaps enumerate the three cases that need this?

I amended the comment.

There are three widget-show cases, but when we go through
RenderViewImpl::Initialize we know we are in the popup case. The other two
widget-show cases are not RenderViews and don't go through
RenderView::Initialize; however, there are also browser-initiated
RenderView-creation cases that go through RenderView::Initialize with a null
show callback, so they aren't widget-show cases. This did_show_ assignment is
for the latter group.

Making it even more confusing, the other two widget-show cases do interact with
their opener RenderView, via the callback. It will hopefully be somewhat clearer
once these callbacks are moved to RenderFrame.

https://codereview.chromium.org/2498463002/diff/200001/content/renderer/rende...
content/renderer/render_view_impl.cc:1949: // that was created via
RenderViewImpl::CreateWebView.  So, we wait until this
On 2016/11/17 09:51:09, alexmos wrote:
> Perhaps update this while you're here?

Done.

https://codereview.chromium.org/2498463002/diff/200001/content/renderer/rende...
content/renderer/render_view_impl.cc:1956: if (did_show_ &&
!webkit_preferences_.supports_multiple_windows) {
On 2016/11/17 09:51:09, alexmos wrote:
> Just to confirm, the NOTREACHED is gone because if we get here with did_show_
> and supports_multiple_windows both being true, we'll hit the DCHECK in
> RenderWidget::show instead?

Correct.

https://codereview.chromium.org/2498463002/diff/200001/content/renderer/rende...
File content/renderer/render_view_impl.h (right):

https://codereview.chromium.org/2498463002/diff/200001/content/renderer/rende...
content/renderer/render_view_impl.h:844: // Whether this was a renderer-created
or browser-created webview.
On 2016/11/17 09:51:09, alexmos wrote:
> nit: webview -> view or RenderView

Done.

https://codereview.chromium.org/2498463002/diff/200001/content/renderer/rende...
File content/renderer/render_widget.h (left):

https://codereview.chromium.org/2498463002/diff/200001/content/renderer/rende...
content/renderer/render_widget.h:631: int32_t opener_id_;
On 2016/11/17 09:51:09, alexmos wrote:
> Hooray!  Glad to see it gone.

Acknowledged.

https://codereview.chromium.org/2498463002/diff/200001/content/renderer/rende...
File content/renderer/render_widget_fullscreen_pepper.h (right):

https://codereview.chromium.org/2498463002/diff/200001/content/renderer/rende...
content/renderer/render_widget_fullscreen_pepper.h:26: class RenderFrameImpl;
On 2016/11/17 09:51:09, alexmos wrote:
> where is this needed?

Was cruft; removed.

[ncarter (slow), 2016-11-17 19:34:31]

nick@chromium.org changed reviewers:
+ sgurun@chromium.org

[ncarter (slow), 2016-11-17 19:34:32]

+sgurun: please review the android webview code, as well as the codepaths
leading to it (changes to content_browser_client, render_view_impl, and
render_frame_impl)

[commit-bot: I haz the power, 2016-11-17 21:52:18]

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

[commit-bot: I haz the power, 2016-11-17 21:52:19]

Dry run: This issue passed the CQ dry run.

[alexmos, 2016-11-17 22:27:43]

LGTM

https://codereview.chromium.org/2498463002/diff/200001/android_webview/render...
File android_webview/renderer/aw_content_renderer_client.cc (right):

https://codereview.chromium.org/2498463002/diff/200001/android_webview/render...
android_webview/renderer/aw_content_renderer_client.cc:131: // be deferred until
after the java side has been constructed.
On 2016/11/17 19:33:11, ncarter wrote:
> On 2016/11/17 09:51:09, alexmos wrote:
> > Do you understand this comment?  I can't tell why this would imply the need
> for
> > the opener check and the return false. 
> 
> I interpret this comment to mean: "when a new WebContents is created, there's
a
> built-in chance to hook its initial navigation on the java/browser side, e.g.
> because such creation goes through AwWebContentsDelegate.java or something
> similar." I don't know what java code is actually being referenced.
> 
> This reasoning seems incorrect for subsequent navigations; my goal with these
> edits was to not disturb the existing behavior, and to maybe draw attention to
> this potential bug. I know there's a long term plan to eliminate this method,
so
> preserving weird behavior seems like a reasonable course here, so long as it's
> not insecure. I get the sense that Android Webview has some pretty serious
> reverse-compatibility constraints.
> 
> I am looping sgurun into this CL for the android webview perspective.

Acknowledged.

https://codereview.chromium.org/2498463002/diff/200001/content/renderer/rende...
File content/renderer/render_view_impl.cc (right):

https://codereview.chromium.org/2498463002/diff/200001/content/renderer/rende...
content/renderer/render_view_impl.cc:808: // If this is a popup, we won't be
visible until we ask our opener (via
On 2016/11/17 19:33:11, ncarter wrote:
> On 2016/11/17 09:51:09, alexmos wrote:
> > nit: is it really correct to say "If this is a popup", since we need to call
> > show_callback in all the renderer-initiated cases, including fullscreen
> widgets
> > which aren't popups?  Perhaps enumerate the three cases that need this?
> 
> I amended the comment.
> 
> There are three widget-show cases, but when we go through
> RenderViewImpl::Initialize we know we are in the popup case. The other two
> widget-show cases are not RenderViews and don't go through
> RenderView::Initialize; however, there are also browser-initiated
> RenderView-creation cases that go through RenderView::Initialize with a null
> show callback, so they aren't widget-show cases. This did_show_ assignment is
> for the latter group.
> 
> Making it even more confusing, the other two widget-show cases do interact
with
> their opener RenderView, via the callback. It will hopefully be somewhat
clearer
> once these callbacks are moved to RenderFrame.

Acknowledged.

[ncarter (slow), 2016-11-17 22:54:36]

nick@chromium.org changed reviewers:
+ dcheng@chromium.org

[ncarter (slow), 2016-11-17 22:54:36]

+dcheng for swapped_out_messages.cc

[dcheng, 2016-11-21 11:19:52]

https://codereview.chromium.org/2498463002/diff/220001/content/common/swapped...
File content/common/swapped_out_messages.cc (left):

https://codereview.chromium.org/2498463002/diff/220001/content/common/swapped...
content/common/swapped_out_messages.cc:76: case
ViewHostMsg_ShowFullscreenWidget::ID:
Out of curiosity, why did we move these?

I guess I would have expected the set of can send and can handle messages to
always be in sync, and I'm a bit surprised that that's not true.

https://codereview.chromium.org/2498463002/diff/220001/content/renderer/rende...
File content/renderer/render_view_impl.h (right):

https://codereview.chromium.org/2498463002/diff/220001/content/renderer/rende...
content/renderer/render_view_impl.h:105: class RenderWidgetFullscreen;
Is this needed?

[sgurun-gerrit only, 2016-11-21 19:03:53]

On 2016/11/21 11:19:52, dcheng wrote:
>
https://codereview.chromium.org/2498463002/diff/220001/content/common/swapped...
> File content/common/swapped_out_messages.cc (left):
> 
>
https://codereview.chromium.org/2498463002/diff/220001/content/common/swapped...
> content/common/swapped_out_messages.cc:76: case
> ViewHostMsg_ShowFullscreenWidget::ID:
> Out of curiosity, why did we move these?
> 
> I guess I would have expected the set of can send and can handle messages to
> always be in sync, and I'm a bit surprised that that's not true.
> 
>
https://codereview.chromium.org/2498463002/diff/220001/content/renderer/rende...
> File content/renderer/render_view_impl.h (right):
> 
>
https://codereview.chromium.org/2498463002/diff/220001/content/renderer/rende...
> content/renderer/render_view_impl.h:105: class RenderWidgetFullscreen;
> Is this needed?

sorry I was late on this CL. Looking today.

[ncarter (slow), 2016-11-21 19:51:25]

https://codereview.chromium.org/2498463002/diff/220001/content/common/swapped...
File content/common/swapped_out_messages.cc (left):

https://codereview.chromium.org/2498463002/diff/220001/content/common/swapped...
content/common/swapped_out_messages.cc:76: case
ViewHostMsg_ShowFullscreenWidget::ID:
On 2016/11/21 11:19:52, dcheng wrote:
> Out of curiosity, why did we move these?
> 
> I guess I would have expected the set of can send and can handle messages to
> always be in sync, and I'm a bit surprised that that's not true.

I didn't change when these messages were sent, but I did change the IPC::Sender
via which they were sent -- they used to be sent via the RenderWidget targeting
a cached value of the view's route_id. When I moved them to the RenderView, it
broke window.open from oopifs and this was the fix.

I agree with you that CanHandle but not CanSend is a weird convention. Here is
what I previously assumed: that it was plausible in the ACK-required case, where
the RFH swaps out but still wants to ACK messages sent by the RF's RenderView
that were sent prior to the RF before the RF knew it was swapped out.

However, looking at the code, the CanHandleWhileSwappedOut restriction seems to
start being applied only after after the SwapOut_ACK arrives in the RFH, so this
isn't plausible. In other words, I think you're right.

So we probably ought to combine these two cases. I also strongly suspect that
the FrameHostMsg's are totally unnecessary in this list here, since we don't
seem to actually apply this filter for the RFH's OnMessageReceived, nor does the
RenderFrame's Send doesn't go through the RenderView. I'll try to clean it all
up in a subsequent patch.

https://codereview.chromium.org/2498463002/diff/220001/content/renderer/rende...
File content/renderer/render_view_impl.h (right):

https://codereview.chromium.org/2498463002/diff/220001/content/renderer/rende...
content/renderer/render_view_impl.h:105: class RenderWidgetFullscreen;
On 2016/11/21 11:19:52, dcheng wrote:
> Is this needed?

Done.

[sgurun-gerrit only, 2016-11-21 21:17:25]

lgtm

https://codereview.chromium.org/2498463002/diff/220001/android_webview/render...
File android_webview/renderer/aw_content_renderer_client.cc (right):

https://codereview.chromium.org/2498463002/diff/220001/android_webview/render...
android_webview/renderer/aw_content_renderer_client.cc:138: // initiated.
yes, we have many bugs we are receiving there. but our cl to move away from this
was reverted multiple times. We will try again.

[dcheng, 2016-11-21 22:41:19]

lgtm

[ncarter (slow), 2016-11-21 23:35:04]

The CQ bit was checked by nick@chromium.org

[ncarter (slow), 2016-11-21 23:35:04]

The patchset sent to the CQ was uploaded after l-g-t-m from lfg@chromium.org,
alexmos@chromium.org
Link to the patchset: https://codereview.chromium.org/2498463002/#ps240001
(title: "Remove RenderWidgetFullscreen")

[commit-bot: I haz the power, 2016-11-21 23:35:50]

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, 2016-11-22 00:04:16]

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

[commit-bot: I haz the power, 2016-11-22 00:04:17]

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

[ncarter (slow), 2016-11-22 00:23:46]

The CQ bit was checked by nick@chromium.org

[commit-bot: I haz the power, 2016-11-22 00:24:11]

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, 2016-11-22 01:08:24]

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

[commit-bot: I haz the power, 2016-11-22 01:08:27]

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

[ncarter (slow), 2016-11-22 21:34:09]

The CQ bit was checked by nick@chromium.org

[commit-bot: I haz the power, 2016-11-22 21:34:52]

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, 2016-11-22 21:59:41]

CQ is committing da patch.

Bot data: {"patchset_id": 240001, "attempt_start_ts": 1479850449706880,
"parent_rev": "a80e34c9bf224e4c767647933c2f6fca4f0ad093", "commit_rev":
"9a488b63ce8cd6080cc87e1c0950ceb695889b73"}

[commit-bot: I haz the power, 2016-11-22 22:00:07]

Description was changed from

==========
RenderWidget/RenderView: Introduce a callback into the opener RenderViewHost,
that is executed at WebWidgetClient::show() time.  This callback fully replaces
the |opener_id_| and |opened_by_user_gesture_| data members.

Ultimately, there are three variants of ShowCallback: one each to send
ViewHostMsg_ShowWidget, ViewHostMsg_ShowFullscreenWidget, and
ViewHostMsg_ShowView. Encapsulating these in a callback will make it possible to
port these messages from RenderView to RenderFrame independently, without 
further complexity in RenderWidget.

This rearrangement also has the benefit of making the Send() happen on the
object that the message is actually routed by. That should help with later
mojofication.

Remove RenderWidgetFullscreen, which contained no real code after
moving the body of ::show() into the callback. Instead, have
RenderWidgetFullscreenPepper (its only subclass) directly derive from
RenderWidget.

Android Webview's HandleNavigation path had an odd dependency on
|opener_id_| that does not look correct. I've tried to preserve
its behavior with this CL, since this path is deprecated.

BUG=627852
==========

to

==========
RenderWidget/RenderView: Introduce a callback into the opener RenderViewHost,
that is executed at WebWidgetClient::show() time.  This callback fully replaces
the |opener_id_| and |opened_by_user_gesture_| data members.

Ultimately, there are three variants of ShowCallback: one each to send
ViewHostMsg_ShowWidget, ViewHostMsg_ShowFullscreenWidget, and
ViewHostMsg_ShowView. Encapsulating these in a callback will make it possible to
port these messages from RenderView to RenderFrame independently, without 
further complexity in RenderWidget.

This rearrangement also has the benefit of making the Send() happen on the
object that the message is actually routed by. That should help with later
mojofication.

Remove RenderWidgetFullscreen, which contained no real code after
moving the body of ::show() into the callback. Instead, have
RenderWidgetFullscreenPepper (its only subclass) directly derive from
RenderWidget.

Android Webview's HandleNavigation path had an odd dependency on
|opener_id_| that does not look correct. I've tried to preserve
its behavior with this CL, since this path is deprecated.

BUG=627852
==========

[commit-bot: I haz the power, 2016-11-22 22:00:09]

Committed patchset #13 (id:240001)

[commit-bot: I haz the power, 2016-11-22 22:01:45]

Description was changed from

==========
RenderWidget/RenderView: Introduce a callback into the opener RenderViewHost,
that is executed at WebWidgetClient::show() time.  This callback fully replaces
the |opener_id_| and |opened_by_user_gesture_| data members.

Ultimately, there are three variants of ShowCallback: one each to send
ViewHostMsg_ShowWidget, ViewHostMsg_ShowFullscreenWidget, and
ViewHostMsg_ShowView. Encapsulating these in a callback will make it possible to
port these messages from RenderView to RenderFrame independently, without 
further complexity in RenderWidget.

This rearrangement also has the benefit of making the Send() happen on the
object that the message is actually routed by. That should help with later
mojofication.

Remove RenderWidgetFullscreen, which contained no real code after
moving the body of ::show() into the callback. Instead, have
RenderWidgetFullscreenPepper (its only subclass) directly derive from
RenderWidget.

Android Webview's HandleNavigation path had an odd dependency on
|opener_id_| that does not look correct. I've tried to preserve
its behavior with this CL, since this path is deprecated.

BUG=627852
==========

to

==========
RenderWidget/RenderView: Introduce a callback into the opener RenderViewHost,
that is executed at WebWidgetClient::show() time.  This callback fully replaces
the |opener_id_| and |opened_by_user_gesture_| data members.

Ultimately, there are three variants of ShowCallback: one each to send
ViewHostMsg_ShowWidget, ViewHostMsg_ShowFullscreenWidget, and
ViewHostMsg_ShowView. Encapsulating these in a callback will make it possible to
port these messages from RenderView to RenderFrame independently, without
further complexity in RenderWidget.

This rearrangement also has the benefit of making the Send() happen on the
object that the message is actually routed by. That should help with later
mojofication.

Remove RenderWidgetFullscreen, which contained no real code after
moving the body of ::show() into the callback. Instead, have
RenderWidgetFullscreenPepper (its only subclass) directly derive from
RenderWidget.

Android Webview's HandleNavigation path had an odd dependency on
|opener_id_| that does not look correct. I've tried to preserve
its behavior with this CL, since this path is deprecated.

BUG=627852

Committed: https://crrev.com/f7b382233d382060eb1b352aa1ea9dffc36a9e44
Cr-Commit-Position: refs/heads/master@{#433999}
==========

[commit-bot: I haz the power, 2016-11-22 22:01:47]

Patchset 13 (id:??) landed as
https://crrev.com/f7b382233d382060eb1b352aa1ea9dffc36a9e44
Cr-Commit-Position: refs/heads/master@{#433999}