Support tracking focused element for OOPIFs.

Support tracking focused node element for OOPIFs.

Focused elements are tracked by RenderViewHostImpl. Upon a change in focused
element, RenderViewImpl sends ViewHostMsg_FocusedNodeChanged to the browser.

With --site-per-process, RenderViewImpl corresponding to OOPIFs is swapped
out and cannot send the IPC. Even by allowing sending such IPCs in swapped
out state, the RenderViewHost cannot properly handle them when there are
multiple RenderWidgetHosts (same process) on the page. This is now causing
regressions with OSK for windows tablets.

This CL will move the logic from RenderViewImpl to RenderFrameImpl.
When focus moves from one WebNode to another, the corresponding frames are
already getting notified by RenderViewImpl. This CL relieves RenderViewImpl
from sending the IPC, and reuses the RenderFrameImpl::FocusNodeChanged() for
sending the update to RenderFrameHostImpl, which then stores the state and
notifies its delegate (WebContentsImpl) about the change.

For similar reasons, the logic to update FocusedNodeTouched is removed from
RenderViewImpl to RenderWidget and is now handled by RenderWidgetHostImpl.

The public API methods in RenderViewHost are unchanged but they are now
handled through RenderViewHostDelegate (WebContentsImpl), which will
query the information or send the command through the focused frame.

BUG=613326
TBR=creis@chromium.org
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation

Committed: https://crrev.com/a110f64a89bad15abb5322be8e720fae40a0f7f1
Cr-Commit-Position: refs/heads/master@{#440185}

[EhsanK, 2016-12-14 03:43:01]

Description was changed from

==========
Move focused element tracking logic to RenderFrame

Focused elements are tracked by RenderViewHostImpl. Upon a change in focused
element, RenderViewImpl sends ViewHostMsg_FocusedNodeChanged to the browser.

With --site-per-process, RenderViewImpl corresponding to OOPIFs is swapped
out and cannot send the IPC. Even by allowing sending such IPCs in swapped
out state, the RenderViewHost cannot properly handle them when there are
multiple RenderWidgetHosts (same process) on the page. This is now causing
regressions with OSK for windows tablets.

This CL will move the logic from RenderViewImpl to RenderFrameImpl.
When focus moves from one WebNode to another, the corresponding frames are
already getting notified by RenderViewImpl. This CL relieves RenderViewImpl
from sending the IPC, and reuses the RenderFrameImpl::FocusNodeChanged() for
sending the update to RenderFrameHostImpl, which then stores the state and
notifies its delegate (WebContentsImpl) about the change.

The public API methods in RenderViewHost are unchanged but they are now
handled through RenderViewHostDelegate (WebContentsImpl), which will
query the information or send the command through the focused frame.

BUG=613326
==========

to

==========
Move focused element tracking logic to RenderFrame

Focused elements are tracked by RenderViewHostImpl. Upon a change in focused
element, RenderViewImpl sends ViewHostMsg_FocusedNodeChanged to the browser.

With --site-per-process, RenderViewImpl corresponding to OOPIFs is swapped
out and cannot send the IPC. Even by allowing sending such IPCs in swapped
out state, the RenderViewHost cannot properly handle them when there are
multiple RenderWidgetHosts (same process) on the page. This is now causing
regressions with OSK for windows tablets.

This CL will move the logic from RenderViewImpl to RenderFrameImpl.
When focus moves from one WebNode to another, the corresponding frames are
already getting notified by RenderViewImpl. This CL relieves RenderViewImpl
from sending the IPC, and reuses the RenderFrameImpl::FocusNodeChanged() for
sending the update to RenderFrameHostImpl, which then stores the state and
notifies its delegate (WebContentsImpl) about the change.

The public API methods in RenderViewHost are unchanged but they are now
handled through RenderViewHostDelegate (WebContentsImpl), which will
query the information or send the command through the focused frame.

BUG=613326
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation
==========

[EhsanK, 2016-12-14 03:43:08]

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

[commit-bot: I haz the power, 2016-12-14 03:43:37]

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-12-14 03:47:29]

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

[commit-bot: I haz the power, 2016-12-14 03:47:29]

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...)
  cast_shell_android on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/cast_shell_a...)
  cast_shell_linux on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/cast_shell_linu...)
  chromeos_amd64-generic_chromium_compile_only_ng on
master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromeos_amd64-...)
  chromeos_daisy_chromium_compile_only_ng on master.tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromeos_daisy_...)
  linux_chromium_asan_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  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_site_isolation on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_site_isol...)

[EhsanK, 2016-12-14 23:32:36]

Description was changed from

==========
Move focused element tracking logic to RenderFrame

Focused elements are tracked by RenderViewHostImpl. Upon a change in focused
element, RenderViewImpl sends ViewHostMsg_FocusedNodeChanged to the browser.

With --site-per-process, RenderViewImpl corresponding to OOPIFs is swapped
out and cannot send the IPC. Even by allowing sending such IPCs in swapped
out state, the RenderViewHost cannot properly handle them when there are
multiple RenderWidgetHosts (same process) on the page. This is now causing
regressions with OSK for windows tablets.

This CL will move the logic from RenderViewImpl to RenderFrameImpl.
When focus moves from one WebNode to another, the corresponding frames are
already getting notified by RenderViewImpl. This CL relieves RenderViewImpl
from sending the IPC, and reuses the RenderFrameImpl::FocusNodeChanged() for
sending the update to RenderFrameHostImpl, which then stores the state and
notifies its delegate (WebContentsImpl) about the change.

The public API methods in RenderViewHost are unchanged but they are now
handled through RenderViewHostDelegate (WebContentsImpl), which will
query the information or send the command through the focused frame.

BUG=613326
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation
==========

to

==========
Move focused element tracking logic to RenderFrame

Focused elements are tracked by RenderViewHostImpl. Upon a change in focused
element, RenderViewImpl sends ViewHostMsg_FocusedNodeChanged to the browser.

With --site-per-process, RenderViewImpl corresponding to OOPIFs is swapped
out and cannot send the IPC. Even by allowing sending such IPCs in swapped
out state, the RenderViewHost cannot properly handle them when there are
multiple RenderWidgetHosts (same process) on the page. This is now causing
regressions with OSK for windows tablets.

This CL will move the logic from RenderViewImpl to RenderFrameImpl.
When focus moves from one WebNode to another, the corresponding frames are
already getting notified by RenderViewImpl. This CL relieves RenderViewImpl
from sending the IPC, and reuses the RenderFrameImpl::FocusNodeChanged() for
sending the update to RenderFrameHostImpl, which then stores the state and
notifies its delegate (WebContentsImpl) about the change.

For similar reasons, the logic to update FocusedNodeTouched is removed from
RenderViewImpl to RenderWidget and is now handled by RenderWidgetHostImpl.

The public API methods in RenderViewHost are unchanged but they are now
handled through RenderViewHostDelegate (WebContentsImpl), which will
query the information or send the command through the focused frame.

BUG=613326
==========

[EhsanK, 2016-12-14 23:32:49]

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

[EhsanK, 2016-12-14 23:32:58]

Patchset #1 (id:1) has been deleted

[commit-bot: I haz the power, 2016-12-14 23:33:42]

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-12-14 23:52:44]

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

[commit-bot: I haz the power, 2016-12-14 23:52:44]

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

[EhsanK, 2016-12-15 00:02:36]

Description was changed from

==========
Move focused element tracking logic to RenderFrame

Focused elements are tracked by RenderViewHostImpl. Upon a change in focused
element, RenderViewImpl sends ViewHostMsg_FocusedNodeChanged to the browser.

With --site-per-process, RenderViewImpl corresponding to OOPIFs is swapped
out and cannot send the IPC. Even by allowing sending such IPCs in swapped
out state, the RenderViewHost cannot properly handle them when there are
multiple RenderWidgetHosts (same process) on the page. This is now causing
regressions with OSK for windows tablets.

This CL will move the logic from RenderViewImpl to RenderFrameImpl.
When focus moves from one WebNode to another, the corresponding frames are
already getting notified by RenderViewImpl. This CL relieves RenderViewImpl
from sending the IPC, and reuses the RenderFrameImpl::FocusNodeChanged() for
sending the update to RenderFrameHostImpl, which then stores the state and
notifies its delegate (WebContentsImpl) about the change.

For similar reasons, the logic to update FocusedNodeTouched is removed from
RenderViewImpl to RenderWidget and is now handled by RenderWidgetHostImpl.

The public API methods in RenderViewHost are unchanged but they are now
handled through RenderViewHostDelegate (WebContentsImpl), which will
query the information or send the command through the focused frame.

BUG=613326
==========

to

==========
Move focused element tracking logic to RenderFrame

Focused elements are tracked by RenderViewHostImpl. Upon a change in focused
element, RenderViewImpl sends ViewHostMsg_FocusedNodeChanged to the browser.

With --site-per-process, RenderViewImpl corresponding to OOPIFs is swapped
out and cannot send the IPC. Even by allowing sending such IPCs in swapped
out state, the RenderViewHost cannot properly handle them when there are
multiple RenderWidgetHosts (same process) on the page. This is now causing
regressions with OSK for windows tablets.

This CL will move the logic from RenderViewImpl to RenderFrameImpl.
When focus moves from one WebNode to another, the corresponding frames are
already getting notified by RenderViewImpl. This CL relieves RenderViewImpl
from sending the IPC, and reuses the RenderFrameImpl::FocusNodeChanged() for
sending the update to RenderFrameHostImpl, which then stores the state and
notifies its delegate (WebContentsImpl) about the change.

For similar reasons, the logic to update FocusedNodeTouched is removed from
RenderViewImpl to RenderWidget and is now handled by RenderWidgetHostImpl.

The public API methods in RenderViewHost are unchanged but they are now
handled through RenderViewHostDelegate (WebContentsImpl), which will
query the information or send the command through the focused frame.

BUG=613326
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation
==========

[EhsanK, 2016-12-15 00:02:49]

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

[EhsanK, 2016-12-15 00:02:54]

Patchset #1 (id:20001) has been deleted

[commit-bot: I haz the power, 2016-12-15 00:03:34]

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

[EhsanK, 2016-12-15 00:05:59]

Description was changed from

==========
Move focused element tracking logic to RenderFrame

Focused elements are tracked by RenderViewHostImpl. Upon a change in focused
element, RenderViewImpl sends ViewHostMsg_FocusedNodeChanged to the browser.

With --site-per-process, RenderViewImpl corresponding to OOPIFs is swapped
out and cannot send the IPC. Even by allowing sending such IPCs in swapped
out state, the RenderViewHost cannot properly handle them when there are
multiple RenderWidgetHosts (same process) on the page. This is now causing
regressions with OSK for windows tablets.

This CL will move the logic from RenderViewImpl to RenderFrameImpl.
When focus moves from one WebNode to another, the corresponding frames are
already getting notified by RenderViewImpl. This CL relieves RenderViewImpl
from sending the IPC, and reuses the RenderFrameImpl::FocusNodeChanged() for
sending the update to RenderFrameHostImpl, which then stores the state and
notifies its delegate (WebContentsImpl) about the change.

For similar reasons, the logic to update FocusedNodeTouched is removed from
RenderViewImpl to RenderWidget and is now handled by RenderWidgetHostImpl.

The public API methods in RenderViewHost are unchanged but they are now
handled through RenderViewHostDelegate (WebContentsImpl), which will
query the information or send the command through the focused frame.

BUG=613326
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation
==========

to

==========
Support tracking focused node element for OOPIFs.

Focused elements are tracked by RenderViewHostImpl. Upon a change in focused
element, RenderViewImpl sends ViewHostMsg_FocusedNodeChanged to the browser.

With --site-per-process, RenderViewImpl corresponding to OOPIFs is swapped
out and cannot send the IPC. Even by allowing sending such IPCs in swapped
out state, the RenderViewHost cannot properly handle them when there are
multiple RenderWidgetHosts (same process) on the page. This is now causing
regressions with OSK for windows tablets.

This CL will move the logic from RenderViewImpl to RenderFrameImpl.
When focus moves from one WebNode to another, the corresponding frames are
already getting notified by RenderViewImpl. This CL relieves RenderViewImpl
from sending the IPC, and reuses the RenderFrameImpl::FocusNodeChanged() for
sending the update to RenderFrameHostImpl, which then stores the state and
notifies its delegate (WebContentsImpl) about the change.

For similar reasons, the logic to update FocusedNodeTouched is removed from
RenderViewImpl to RenderWidget and is now handled by RenderWidgetHostImpl.

The public API methods in RenderViewHost are unchanged but they are now
handled through RenderViewHostDelegate (WebContentsImpl), which will
query the information or send the command through the focused frame.

BUG=613326
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation
==========

[EhsanK, 2016-12-15 00:09:31]

ekaramad@chromium.org changed reviewers:
+ creis@chromium.org

[EhsanK, 2016-12-15 00:09:32]

Hello Charlie,

Could you please review this CL (and/or suggest other reviewers)?

Thanks!

PS: Tested this on a local windows 8 machine.

[Charlie Reis, 2016-12-15 00:13:34]

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

[Charlie Reis, 2016-12-15 00:13:35]

I'm a bit overloaded with reviews at the moment.  Nick, would you be able to
help look at this one to fix Win8 touch keyboards?

[commit-bot: I haz the power, 2016-12-15 00:22:01]

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

[commit-bot: I haz the power, 2016-12-15 00:22:02]

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

[ncarter (slow), 2016-12-15 00:37:47]

nick@chromium.org changed reviewers:
- creis@chromium.org

[ncarter (slow), 2016-12-15 00:37:47]

Yes, I can review this.

[EhsanK, 2016-12-15 07:44:39]

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

[commit-bot: I haz the power, 2016-12-15 07:44:52]

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-12-15 09:18:25]

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

[commit-bot: I haz the power, 2016-12-15 09:18:27]

Dry run: This issue passed the CQ dry run.

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

https://codereview.chromium.org/2571583008/diff/60001/content/browser/frame_h...
File content/browser/frame_host/render_frame_host_delegate.h (right):

https://codereview.chromium.org/2571583008/diff/60001/content/browser/frame_h...
content/browser/frame_host/render_frame_host_delegate.h:221: // element.
|bounds_in_frame_widget| is the rectangle containing the element
|bounds_in_frame_widget| or |bounds_in_root_view|?

https://codereview.chromium.org/2571583008/diff/60001/content/browser/frame_h...
File content/browser/frame_host/render_frame_host_impl.h (right):

https://codereview.chromium.org/2571583008/diff/60001/content/browser/frame_h...
content/browser/frame_host/render_frame_host_impl.h:1084: // If there then this
frame's document has a focused element which editable.
"If there" -> "If true"

"which editable" -> "which is editable"

https://codereview.chromium.org/2571583008/diff/60001/content/browser/rendere...
File content/browser/renderer_host/render_view_host_delegate.h (right):

https://codereview.chromium.org/2571583008/diff/60001/content/browser/rendere...
content/browser/renderer_host/render_view_host_delegate.h:239: virtual void
ClearFocusedElement(){};
space before {}

https://codereview.chromium.org/2571583008/diff/60001/content/browser/rendere...
File content/browser/renderer_host/render_view_host_impl.cc (right):

https://codereview.chromium.org/2571583008/diff/60001/content/browser/rendere...
content/browser/renderer_host/render_view_host_impl.cc:971: void
RenderViewHostImpl::ClearFocusedElement() {
Should we consider just moving this method to be part of WebContents' public
interface? Seems like there's just one call, and it would be a trivial change to
make, and less code overall.

https://codereview.chromium.org/2571583008/diff/60001/content/browser/rendere...
content/browser/renderer_host/render_view_host_impl.cc:976: bool
RenderViewHostImpl::IsFocusedElementEditable() {
Same question here. There are a couple more callers, but they're all of the form
web_contents()->GetRVH()->IsFocusedElementEditable.

https://codereview.chromium.org/2571583008/diff/60001/content/browser/rendere...
File content/browser/renderer_host/render_widget_host_impl.cc (right):

https://codereview.chromium.org/2571583008/diff/60001/content/browser/rendere...
content/browser/renderer_host/render_widget_host_impl.cc:1488: }
add a blank line here.

https://codereview.chromium.org/2571583008/diff/60001/content/browser/rendere...
File content/browser/renderer_host/render_widget_host_view_aura.cc (right):

https://codereview.chromium.org/2571583008/diff/60001/content/browser/rendere...
content/browser/renderer_host/render_widget_host_view_aura.cc:800: host,
location_dips_screen, device_scale_factor_, window_));
I'm thinking about the case here where (host_ != host), and the layering looks a
little odd.

Doesn't |host| have its own RWHView? It seems kind of strange for RWHVAura to
provide this service to other RWHs, and to have a |keyboard_observer_| member
that holds a pointer to the other |host|.

Among other things, I worry about:
 - what prevents the |host| pointer passed to WinScreenKeyboardObserver from
becoming invalid in the oopif case, if, say, it's an oopif widget whose FTN is
destroyed by a navigation?
 - When WinScreenKeyboardObserver calls SetInsets on |host|, and host is an
oopif widget, does the right thing happen? It seems like we want to adjust
insets on the outer RWHVAura, not the inner RWHVChildFrame.

https://codereview.chromium.org/2571583008/diff/60001/content/browser/web_con...
File content/browser/web_contents/web_contents_impl.cc (right):

https://codereview.chromium.org/2571583008/diff/60001/content/browser/web_con...
content/browser/web_contents/web_contents_impl.cc:4736: // changes to public
API.
WebContents can be made to be the source (and, I think, it would make it
consistent with moving the other focus methods from render_view_host.h to
web_contents.h).

Even better, though more work, would be to move it to WebContentsObserver.

I agree with leaving this as a TODO rather than tackling it in this CL, though;
looks like there are several listeners.

https://codereview.chromium.org/2571583008/diff/60001/content/renderer/render...
File content/renderer/render_frame_impl.cc (right):

https://codereview.chromium.org/2571583008/diff/60001/content/renderer/render...
content/renderer/render_frame_impl.cc:5587: // RenderViewImpl?
What is the concern here? Do you think we might have correctness bugs when doing
in-process, cross-frame focus traversal?

In general I would expect it should suffice to maintain a deterministic ordering
between the focus and focus-clear operations, and then we can reasonably
implement this in terms of one RFH.

Adding special-cases for same-process behavior increases the possibility of
behavioral drift between the oopif and non-oopif cases, so I prefer purely
frame-based operations, where feasible.

[EhsanK, 2016-12-20 16:39:11]

Thanks Nick! PTAL.

So far, the only outstanding issue seems to be scrolling the editable element
when it is inside an OOPIF. I think we need to scroll the OOPIFs and then scroll
the edtiable element inside the focused frame. I have been working on it.

We could also work on this patch as is (in terms of what it implements) and then
fix the scrolling later as TODO. I will try to get the scrolling work soon but
in case the rest of it LGTY before that, maybe we can land this part and have a
followup fix for scrolling. WDYT?

Thanks!

https://codereview.chromium.org/2571583008/diff/60001/content/browser/frame_h...
File content/browser/frame_host/render_frame_host_delegate.h (right):

https://codereview.chromium.org/2571583008/diff/60001/content/browser/frame_h...
content/browser/frame_host/render_frame_host_delegate.h:221: // element.
|bounds_in_frame_widget| is the rectangle containing the element
On 2016/12/16 19:17:20, ncarter wrote:
> |bounds_in_frame_widget| or |bounds_in_root_view|?

Sorry. |boudns_in_root_view|. Thanks! Done.

https://codereview.chromium.org/2571583008/diff/60001/content/browser/frame_h...
File content/browser/frame_host/render_frame_host_impl.h (right):

https://codereview.chromium.org/2571583008/diff/60001/content/browser/frame_h...
content/browser/frame_host/render_frame_host_impl.h:1084: // If there then this
frame's document has a focused element which editable.
On 2016/12/16 19:17:21, ncarter wrote:
> "If there" -> "If true"
> 
> "which editable" -> "which is editable"

Thanks! Done.

https://codereview.chromium.org/2571583008/diff/60001/content/browser/rendere...
File content/browser/renderer_host/render_view_host_delegate.h (right):

https://codereview.chromium.org/2571583008/diff/60001/content/browser/rendere...
content/browser/renderer_host/render_view_host_delegate.h:239: virtual void
ClearFocusedElement(){};
On 2016/12/16 19:17:21, ncarter wrote:
> space before {}

Thanks! I think the ; thew git cl format off.

https://codereview.chromium.org/2571583008/diff/60001/content/browser/rendere...
File content/browser/renderer_host/render_view_host_impl.cc (right):

https://codereview.chromium.org/2571583008/diff/60001/content/browser/rendere...
content/browser/renderer_host/render_view_host_impl.cc:971: void
RenderViewHostImpl::ClearFocusedElement() {
On 2016/12/16 19:17:21, ncarter wrote:
> Should we consider just moving this method to be part of WebContents' public
> interface? Seems like there's just one call, and it would be a trivial change
to
> make, and less code overall.

Yes absolutely. I didn't do this for two reasons:
1- Wasn't sure if this concept is a WebContents thing
2- Wasn't sure if I should modify public API and the corresponding changes in
tests and other files in this patch (which might merge to M56).

But I think the logic should be in WebContentsImpl in general unless we want to
use GetFocusedFrame() inside RenderViewHost.

https://codereview.chromium.org/2571583008/diff/60001/content/browser/rendere...
content/browser/renderer_host/render_view_host_impl.cc:976: bool
RenderViewHostImpl::IsFocusedElementEditable() {
On 2016/12/16 19:17:21, ncarter wrote:
> Same question here. There are a couple more callers, but they're all of the
form
> web_contents()->GetRVH()->IsFocusedElementEditable.

+1 to moving to WebContentsImpl. Maybe I leave a TODO here?

https://codereview.chromium.org/2571583008/diff/60001/content/browser/rendere...
File content/browser/renderer_host/render_widget_host_impl.cc (right):

https://codereview.chromium.org/2571583008/diff/60001/content/browser/rendere...
content/browser/renderer_host/render_widget_host_impl.cc:1488: }
On 2016/12/16 19:17:21, ncarter wrote:
> add a blank line here.

Done.

https://codereview.chromium.org/2571583008/diff/60001/content/browser/rendere...
File content/browser/renderer_host/render_widget_host_view_aura.cc (right):

https://codereview.chromium.org/2571583008/diff/60001/content/browser/rendere...
content/browser/renderer_host/render_widget_host_view_aura.cc:191:
host_->ScrollFocusedEditableNodeIntoRect(node_rect);
This is the spot which needs to get fixed. Since we work on focused frame (i.e.,
focused element is in focused frame), getting the right widget is easy with
RenderWidgetHostDelegate::GetFocusedRenderWidgetHost().

However, just doing that does not fix the issue (i.e., tapping the <input> in an
OOPIF does not do the right scrolling (up) thing.

I think we need to add another method to first scroll the corresponding <iframe>
up in the middle or top of the screen. This should happen in OOPIF's parent's
process. Then calling this on the focused widget will hopefully bring up the
<input> properly.

https://codereview.chromium.org/2571583008/diff/60001/content/browser/rendere...
content/browser/renderer_host/render_widget_host_view_aura.cc:800: host,
location_dips_screen, device_scale_factor_, window_));
On 2016/12/16 19:17:21, ncarter wrote:
> I'm thinking about the case here where (host_ != host), and the layering looks
a
> little odd.
Agreed. It is probably actually incorrect.

> Doesn't |host| have its own RWHView? It seems kind of strange for RWHVAura to
> provide this service to other RWHs, and to have a |keyboard_observer_| member
> that holds a pointer to the other |host|.
I think given that this is a page thing, RWHVAura should be a good place for
keeping keyboard reference. But |host| should not be that of a child frame.

> Among other things, I worry about:
>  - what prevents the |host| pointer passed to WinScreenKeyboardObserver from
> becoming invalid in the oopif case, if, say, it's an oopif widget whose FTN is
> destroyed by a navigation?
Unfortunately nothing. If the RenderFrame goes out normally, we get a focused
node changed which will reset this. But I tested a case where I crashed the
renderer and this caused a browser crash.
>  - When WinScreenKeyboardObserver calls SetInsets on |host|, and host is an
> oopif widget, does the right thing happen? It seems like we want to adjust
> insets on the outer RWHVAura, not the inner RWHVChildFrame.
I think (frome the comments in render_widget_host_view.h) this method should
only be called on page level view. So I should actually pass the old |host_|
instead of |host|.

But the scrolling for focused node will be broken and that needs extra fixes
that I am working on now. I left a comment above where the change should occur.

https://codereview.chromium.org/2571583008/diff/60001/content/browser/web_con...
File content/browser/web_contents/web_contents_impl.cc (right):

https://codereview.chromium.org/2571583008/diff/60001/content/browser/web_con...
content/browser/web_contents/web_contents_impl.cc:4736: // changes to public
API.
On 2016/12/16 19:17:21, ncarter wrote:
> WebContents can be made to be the source (and, I think, it would make it
> consistent with moving the other focus methods from render_view_host.h to
> web_contents.h).
> 
> Even better, though more work, would be to move it to WebContentsObserver.
> 
> I agree with leaving this as a TODO rather than tackling it in this CL,
though;
> looks like there are several listeners.

Yes I am not quite fond of notifications as they confuse me. I will add a TODO
here. So in conclusion, we move the two methods in RVH to WebContents and add an
observer call to WebContentsObserver (in a followup patch).

https://codereview.chromium.org/2571583008/diff/60001/content/renderer/render...
File content/renderer/render_frame_impl.cc (right):

https://codereview.chromium.org/2571583008/diff/60001/content/renderer/render...
content/renderer/render_frame_impl.cc:5587: // RenderViewImpl?
My concern was that we end up calling webview->clearFocusedElement() which is
doing it for the page. This includes finding the focused frame and then clearing
the element on its document.

But if we are already at the right RFH (since we sent it to the focused frame
from browser), then why do that? We should maybe separate the logic for clearing
the document and doing the layout into a method in WebLocalFrame and use it
here.

For clearing the element on page, we can modify the webview method to get the
focused frame and call clear on that. WDYT?

The only issue would be that the focused frame on the renderer might change
while the IPC is enroute to renderer. But I don't think that is an issue here.

[EhsanK, 2016-12-20 16:39:35]

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

[commit-bot: I haz the power, 2016-12-20 16:39:59]

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-12-20 22:37:45]

lgtm

https://codereview.chromium.org/2571583008/diff/60001/content/browser/web_con...
File content/browser/web_contents/web_contents_impl.cc (right):

https://codereview.chromium.org/2571583008/diff/60001/content/browser/web_con...
content/browser/web_contents/web_contents_impl.cc:4736: // changes to public
API.
On 2016/12/20 16:39:11, EhsanK wrote:
> On 2016/12/16 19:17:21, ncarter wrote:
> > WebContents can be made to be the source (and, I think, it would make it
> > consistent with moving the other focus methods from render_view_host.h to
> > web_contents.h).
> > 
> > Even better, though more work, would be to move it to WebContentsObserver.
> > 
> > I agree with leaving this as a TODO rather than tackling it in this CL,
> though;
> > looks like there are several listeners.
> 
> Yes I am not quite fond of notifications as they confuse me. I will add a TODO
> here. So in conclusion, we move the two methods in RVH to WebContents and add
an
> observer call to WebContentsObserver (in a followup patch).

SGTM!

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

https://codereview.chromium.org/2571583008/diff/120001/content/renderer/rende...
content/renderer/render_frame_impl.cc:5600: // TODO(ekaramad): Should we add a
method to WebLocalFrame instead and avoic
avoic -> avoid

[EhsanK, 2016-12-20 23:03:24]

ekaramad@chromium.org changed reviewers:
+ creis@chromium.org, kenrb@chromium.org

[EhsanK, 2016-12-20 23:03:25]

Thanks Nick!

Adding creis@ again for the missing permission on the test file (apparently only
creis@ owns this file).

Adding kenrb@ for the message files owner's approval.

PTAL.

[EhsanK, 2016-12-21 16:04:31]

Description was changed from

==========
Support tracking focused node element for OOPIFs.

Focused elements are tracked by RenderViewHostImpl. Upon a change in focused
element, RenderViewImpl sends ViewHostMsg_FocusedNodeChanged to the browser.

With --site-per-process, RenderViewImpl corresponding to OOPIFs is swapped
out and cannot send the IPC. Even by allowing sending such IPCs in swapped
out state, the RenderViewHost cannot properly handle them when there are
multiple RenderWidgetHosts (same process) on the page. This is now causing
regressions with OSK for windows tablets.

This CL will move the logic from RenderViewImpl to RenderFrameImpl.
When focus moves from one WebNode to another, the corresponding frames are
already getting notified by RenderViewImpl. This CL relieves RenderViewImpl
from sending the IPC, and reuses the RenderFrameImpl::FocusNodeChanged() for
sending the update to RenderFrameHostImpl, which then stores the state and
notifies its delegate (WebContentsImpl) about the change.

For similar reasons, the logic to update FocusedNodeTouched is removed from
RenderViewImpl to RenderWidget and is now handled by RenderWidgetHostImpl.

The public API methods in RenderViewHost are unchanged but they are now
handled through RenderViewHostDelegate (WebContentsImpl), which will
query the information or send the command through the focused frame.

BUG=613326
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation
==========

to

==========
Support tracking focused node element for OOPIFs.

Focused elements are tracked by RenderViewHostImpl. Upon a change in focused
element, RenderViewImpl sends ViewHostMsg_FocusedNodeChanged to the browser.

With --site-per-process, RenderViewImpl corresponding to OOPIFs is swapped
out and cannot send the IPC. Even by allowing sending such IPCs in swapped
out state, the RenderViewHost cannot properly handle them when there are
multiple RenderWidgetHosts (same process) on the page. This is now causing
regressions with OSK for windows tablets.

This CL will move the logic from RenderViewImpl to RenderFrameImpl.
When focus moves from one WebNode to another, the corresponding frames are
already getting notified by RenderViewImpl. This CL relieves RenderViewImpl
from sending the IPC, and reuses the RenderFrameImpl::FocusNodeChanged() for
sending the update to RenderFrameHostImpl, which then stores the state and
notifies its delegate (WebContentsImpl) about the change.

For similar reasons, the logic to update FocusedNodeTouched is removed from
RenderViewImpl to RenderWidget and is now handled by RenderWidgetHostImpl.

The public API methods in RenderViewHost are unchanged but they are now
handled through RenderViewHostDelegate (WebContentsImpl), which will
query the information or send the command through the focused frame.

BUG=613326
TBR=creis@chromium.org
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation
==========

[EhsanK, 2016-12-21 16:04:31]

ekaramad@chromium.org changed reviewers:
- creis@chromium.org

[EhsanK, 2016-12-21 16:08:38]

On 2016/12/20 23:03:25, EhsanK wrote:
> Thanks Nick!
> 
> Adding creis@ again for the missing permission on the test file (apparently
only
> creis@ owns this file).
> 
> Adding kenrb@ for the message files owner's approval.
> 
> PTAL.

- creis@ since he is OOO
+ TBR=creis@

[nasko, 2016-12-21 16:28:35]

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

[nasko, 2016-12-21 16:28:36]

LGTM with some nits.

https://codereview.chromium.org/2571583008/diff/140001/content/common/frame_m...
File content/common/frame_messages.h (right):

https://codereview.chromium.org/2571583008/diff/140001/content/common/frame_m...
content/common/frame_messages.h:1122: // The second parameter is the node bounds
relative to local roots
nit: root or root's?

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

https://codereview.chromium.org/2571583008/diff/140001/content/renderer/rende...
content/renderer/render_frame_impl.cc:5025: is_editable = element.isEditable();
very minor nit: since is_editable is the first parameter, I'd put it as the
first line in that if block.

https://codereview.chromium.org/2571583008/diff/140001/content/renderer/rende...
content/renderer/render_frame_impl.cc:5027: Send(new
FrameHostMsg_FocusedNodeChanged(GetRoutingID(), is_editable,
Just routing_id_ as the rest of the Send() methods use it.

[EhsanK, 2016-12-21 16:37:05]

ekaramad@chromium.org changed reviewers:
- kenrb@chromium.org

[EhsanK, 2016-12-21 16:37:06]

Thanks nasko@! I will try to CQ now.

Also -kenrb@ since nasko@ reviewed as security owner.

https://codereview.chromium.org/2571583008/diff/140001/content/common/frame_m...
File content/common/frame_messages.h (right):

https://codereview.chromium.org/2571583008/diff/140001/content/common/frame_m...
content/common/frame_messages.h:1122: // The second parameter is the node bounds
relative to local roots
On 2016/12/21 16:28:36, nasko wrote:
> nit: root or root's?

root's. Thanks!

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

https://codereview.chromium.org/2571583008/diff/140001/content/renderer/rende...
content/renderer/render_frame_impl.cc:5025: is_editable = element.isEditable();
On 2016/12/21 16:28:36, nasko wrote:
> very minor nit: since is_editable is the first parameter, I'd put it as the
> first line in that if block.

Acknowledged.

https://codereview.chromium.org/2571583008/diff/140001/content/renderer/rende...
content/renderer/render_frame_impl.cc:5027: Send(new
FrameHostMsg_FocusedNodeChanged(GetRoutingID(), is_editable,
On 2016/12/21 16:28:36, nasko wrote:
> Just routing_id_ as the rest of the Send() methods use it.

Acknowledged.

[EhsanK, 2016-12-21 16:37:17]

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

[commit-bot: I haz the power, 2016-12-21 16:37:38]

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

[EhsanK, 2016-12-21 18:07:53]

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

[commit-bot: I haz the power, 2016-12-21 18:08:19]

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

[EhsanK, 2016-12-21 18:37:01]

The CQ bit was unchecked by ekaramad@chromium.org

[EhsanK, 2016-12-21 18:37:06]

The CQ bit was checked by ekaramad@chromium.org

[EhsanK, 2016-12-21 18:37:07]

The patchset sent to the CQ was uploaded after l-g-t-m from nick@chromium.org,
nasko@chromium.org
Link to the patchset: https://codereview.chromium.org/2571583008/#ps180001
(title: "Do not call ScrollFocusedEditableNodeIntoRect for OOPIFs.")

[commit-bot: I haz the power, 2016-12-21 18:37:45]

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

[ncarter (slow), 2016-12-21 18:46:09]

lgtm

https://codereview.chromium.org/2571583008/diff/180001/content/browser/render...
File content/browser/renderer_host/render_widget_host_view_aura.cc (right):

https://codereview.chromium.org/2571583008/diff/180001/content/browser/render...
content/browser/renderer_host/render_widget_host_view_aura.cc:186: // inside an
OOPIF (https://crbug.com/676037).
As we discussed over chat, we may actually never need to ask anything but the
outermost view to scroll (we don't need to scroll within iframes, because we
don't expect the iframe bounds within the document to change), so for this
codepath at least it is probably not necessary to bubble a scroll event up. This
is borne out of the fact that for non-oopif nested iframes, the code in
WebViewImpl doesn't seem to currently do a recursive scroll-into-view loop. (if
we ever do need to implement that, find-in-page and focus traversal already need
to do it, so maybe there is code we can reuse.)

What it sounds like we *do* need to do, is notify the element itself to finish
the focus change, which may mean sending a separate message to focused widget
(something that currently happens as a side effect of
ScrollFocusedEditableNodeIntoRect?)

https://codereview.chromium.org/2571583008/diff/180001/content/browser/render...
content/browser/renderer_host/render_widget_host_view_aura.cc:190:
host_->ScrollFocusedEditableNodeIntoRect(node_rect);
This change makes sense.

[EhsanK, 2016-12-21 18:49:58]

Thanks Nick! I will try to fix the scrolling issue in a followup CL.

https://codereview.chromium.org/2571583008/diff/180001/content/browser/render...
File content/browser/renderer_host/render_widget_host_view_aura.cc (right):

https://codereview.chromium.org/2571583008/diff/180001/content/browser/render...
content/browser/renderer_host/render_widget_host_view_aura.cc:186: // inside an
OOPIF (https://crbug.com/676037).
On 2016/12/21 18:46:09, ncarter wrote:
> As we discussed over chat, we may actually never need to ask anything but the
> outermost view to scroll (we don't need to scroll within iframes, because we
> don't expect the iframe bounds within the document to change), so for this
> codepath at least it is probably not necessary to bubble a scroll event up.
This
> is borne out of the fact that for non-oopif nested iframes, the code in
> WebViewImpl doesn't seem to currently do a recursive scroll-into-view loop.
(if
> we ever do need to implement that, find-in-page and focus traversal already
need
> to do it, so maybe there is code we can reuse.)
> 
> What it sounds like we *do* need to do, is notify the element itself to finish
> the focus change, which may mean sending a separate message to focused widget
> (something that currently happens as a side effect of
> ScrollFocusedEditableNodeIntoRect?)

Yes agreed. I believe we might need to fix the scroll focused editable element
for other purposes (or not, I am not too sure) such as IME. But as far as OSK
goes, we only need to focus <iframe>.

https://codereview.chromium.org/2571583008/diff/180001/content/browser/render...
content/browser/renderer_host/render_widget_host_view_aura.cc:190:
host_->ScrollFocusedEditableNodeIntoRect(node_rect);
On 2016/12/21 18:46:09, ncarter wrote:
> This change makes sense.

Acknowledged.

[EhsanK, 2016-12-21 18:50:47]

On 2016/12/21 18:49:58, EhsanK wrote:
> Thanks Nick! I will try to fix the scrolling issue in a followup CL.
> 
>
https://codereview.chromium.org/2571583008/diff/180001/content/browser/render...
> File content/browser/renderer_host/render_widget_host_view_aura.cc (right):
> 
>
https://codereview.chromium.org/2571583008/diff/180001/content/browser/render...
> content/browser/renderer_host/render_widget_host_view_aura.cc:186: // inside
an
> OOPIF (https://crbug.com/676037).
> On 2016/12/21 18:46:09, ncarter wrote:
> > As we discussed over chat, we may actually never need to ask anything but
the
> > outermost view to scroll (we don't need to scroll within iframes, because we
> > don't expect the iframe bounds within the document to change), so for this
> > codepath at least it is probably not necessary to bubble a scroll event up.
> This
> > is borne out of the fact that for non-oopif nested iframes, the code in
> > WebViewImpl doesn't seem to currently do a recursive scroll-into-view loop.
> (if
> > we ever do need to implement that, find-in-page and focus traversal already
> need
> > to do it, so maybe there is code we can reuse.)
> > 
> > What it sounds like we *do* need to do, is notify the element itself to
finish
> > the focus change, which may mean sending a separate message to focused
widget
> > (something that currently happens as a side effect of
> > ScrollFocusedEditableNodeIntoRect?)
> 
> Yes agreed. I believe we might need to fix the scroll focused editable element
> for other purposes (or not, I am not too sure) such as IME. But as far as OSK
> goes, we only need to focus <iframe>.
> 
>
https://codereview.chromium.org/2571583008/diff/180001/content/browser/render...
> content/browser/renderer_host/render_widget_host_view_aura.cc:190:
> host_->ScrollFocusedEditableNodeIntoRect(node_rect);
> On 2016/12/21 18:46:09, ncarter wrote:
> > This change makes sense.
> 
> Acknowledged.

s/we only need to focus <iframe>/we only need to scroll <iframe>

[commit-bot: I haz the power, 2016-12-21 19:47:33]

CQ is committing da patch.

Bot data: {"patchset_id": 180001, "attempt_start_ts": 1482345426544470,
"parent_rev": "694bb1edbdf065ea4c52f1b161f2585376342adc", "commit_rev":
"575e7861de3d28d9a01550a742760b21724d8de9"}

[commit-bot: I haz the power, 2016-12-21 19:48:01]

Description was changed from

==========
Support tracking focused node element for OOPIFs.

Focused elements are tracked by RenderViewHostImpl. Upon a change in focused
element, RenderViewImpl sends ViewHostMsg_FocusedNodeChanged to the browser.

With --site-per-process, RenderViewImpl corresponding to OOPIFs is swapped
out and cannot send the IPC. Even by allowing sending such IPCs in swapped
out state, the RenderViewHost cannot properly handle them when there are
multiple RenderWidgetHosts (same process) on the page. This is now causing
regressions with OSK for windows tablets.

This CL will move the logic from RenderViewImpl to RenderFrameImpl.
When focus moves from one WebNode to another, the corresponding frames are
already getting notified by RenderViewImpl. This CL relieves RenderViewImpl
from sending the IPC, and reuses the RenderFrameImpl::FocusNodeChanged() for
sending the update to RenderFrameHostImpl, which then stores the state and
notifies its delegate (WebContentsImpl) about the change.

For similar reasons, the logic to update FocusedNodeTouched is removed from
RenderViewImpl to RenderWidget and is now handled by RenderWidgetHostImpl.

The public API methods in RenderViewHost are unchanged but they are now
handled through RenderViewHostDelegate (WebContentsImpl), which will
query the information or send the command through the focused frame.

BUG=613326
TBR=creis@chromium.org
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation
==========

to

==========
Support tracking focused node element for OOPIFs.

Focused elements are tracked by RenderViewHostImpl. Upon a change in focused
element, RenderViewImpl sends ViewHostMsg_FocusedNodeChanged to the browser.

With --site-per-process, RenderViewImpl corresponding to OOPIFs is swapped
out and cannot send the IPC. Even by allowing sending such IPCs in swapped
out state, the RenderViewHost cannot properly handle them when there are
multiple RenderWidgetHosts (same process) on the page. This is now causing
regressions with OSK for windows tablets.

This CL will move the logic from RenderViewImpl to RenderFrameImpl.
When focus moves from one WebNode to another, the corresponding frames are
already getting notified by RenderViewImpl. This CL relieves RenderViewImpl
from sending the IPC, and reuses the RenderFrameImpl::FocusNodeChanged() for
sending the update to RenderFrameHostImpl, which then stores the state and
notifies its delegate (WebContentsImpl) about the change.

For similar reasons, the logic to update FocusedNodeTouched is removed from
RenderViewImpl to RenderWidget and is now handled by RenderWidgetHostImpl.

The public API methods in RenderViewHost are unchanged but they are now
handled through RenderViewHostDelegate (WebContentsImpl), which will
query the information or send the command through the focused frame.

BUG=613326
TBR=creis@chromium.org
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation

Review-Url: https://codereview.chromium.org/2571583008
==========

[commit-bot: I haz the power, 2016-12-21 19:48:02]

Committed patchset #8 (id:180001)

[commit-bot: I haz the power, 2016-12-21 19:51:45]

Description was changed from

==========
Support tracking focused node element for OOPIFs.

Focused elements are tracked by RenderViewHostImpl. Upon a change in focused
element, RenderViewImpl sends ViewHostMsg_FocusedNodeChanged to the browser.

With --site-per-process, RenderViewImpl corresponding to OOPIFs is swapped
out and cannot send the IPC. Even by allowing sending such IPCs in swapped
out state, the RenderViewHost cannot properly handle them when there are
multiple RenderWidgetHosts (same process) on the page. This is now causing
regressions with OSK for windows tablets.

This CL will move the logic from RenderViewImpl to RenderFrameImpl.
When focus moves from one WebNode to another, the corresponding frames are
already getting notified by RenderViewImpl. This CL relieves RenderViewImpl
from sending the IPC, and reuses the RenderFrameImpl::FocusNodeChanged() for
sending the update to RenderFrameHostImpl, which then stores the state and
notifies its delegate (WebContentsImpl) about the change.

For similar reasons, the logic to update FocusedNodeTouched is removed from
RenderViewImpl to RenderWidget and is now handled by RenderWidgetHostImpl.

The public API methods in RenderViewHost are unchanged but they are now
handled through RenderViewHostDelegate (WebContentsImpl), which will
query the information or send the command through the focused frame.

BUG=613326
TBR=creis@chromium.org
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation

Review-Url: https://codereview.chromium.org/2571583008
==========

to

==========
Support tracking focused node element for OOPIFs.

Focused elements are tracked by RenderViewHostImpl. Upon a change in focused
element, RenderViewImpl sends ViewHostMsg_FocusedNodeChanged to the browser.

With --site-per-process, RenderViewImpl corresponding to OOPIFs is swapped
out and cannot send the IPC. Even by allowing sending such IPCs in swapped
out state, the RenderViewHost cannot properly handle them when there are
multiple RenderWidgetHosts (same process) on the page. This is now causing
regressions with OSK for windows tablets.

This CL will move the logic from RenderViewImpl to RenderFrameImpl.
When focus moves from one WebNode to another, the corresponding frames are
already getting notified by RenderViewImpl. This CL relieves RenderViewImpl
from sending the IPC, and reuses the RenderFrameImpl::FocusNodeChanged() for
sending the update to RenderFrameHostImpl, which then stores the state and
notifies its delegate (WebContentsImpl) about the change.

For similar reasons, the logic to update FocusedNodeTouched is removed from
RenderViewImpl to RenderWidget and is now handled by RenderWidgetHostImpl.

The public API methods in RenderViewHost are unchanged but they are now
handled through RenderViewHostDelegate (WebContentsImpl), which will
query the information or send the command through the focused frame.

BUG=613326
TBR=creis@chromium.org
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation

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

[commit-bot: I haz the power, 2016-12-21 19:51:46]

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