Reland of OOPIF: Route keyboard events to focused frame in the browser process.

Reland of OOPIF: Route keyboard events to focused frame in the browser process. (patchset #1 id:1 of https://codereview.chromium.org/1407173005/ )

Reason for revert:
The flakiness in SitePerProcessBrowserTest.SubframeKeyboardEventRouting should now be fixed.  I suspect the issue was that without knowing which remote frame was focused, the page was setting the main frame as focused frame when the whole window lost/gained focus (e.g., via alt-tab).  With https://codereview.chromium.org/1423053002/, we now know propagate which remote frames are focused, so this shouldn't happen anymore.

Original issue's description:
> Revert of OOPIF: Route keyboard events to focused frame in the browser process. (patchset #11 id:200001 of https://codereview.chromium.org/1405293002/ )
>
> Reason for revert:
> SitePerProcessBrowserTest.SubframeKeyboardEventRouting is flaky on Windows 7.
>
> http://test-results.appspot.com/dashboards/flakiness_dashboard.html#testType=content_browsertests&tests=SitePerProcessBrowserTest.SubframeKeyboardEventRouting
>
> http://build.chromium.org/p/chromium.win/builders/Win7%20Tests%20%281%29/builds/43548/steps/content_browsertests/logs/stdio
>
> Original issue's description:
> > OOPIF: Route keyboard events to focused frame in the browser process.
> >
> > Previously, keyboard events were always routed to the top frame's
> > RenderWidgetHost.  With OOPIF, the top frame then forwarded the event
> > to an appropriate subframe renderer if needed.  The extra hop is
> > inefficient and leaks information; moreover, the forwarding broke when
> > mouse event hit-testing in the browser process was introduced.
> >
> > This CL adds logic to send keyboard events directly to the right
> > RenderWidgetHost in the browser process, using the currently focused
> > frame which is already tracked in each FrameTree.  This should be
> > supported for Aura, Mac, and Android.
> >
> > BUG=530663, 339659
> >
> > Committed: https://crrev.com/e2a1799925ea027bd71ea9367280ddfb4403987a
> > Cr-Commit-Position: refs/heads/master@{#357011}
>
> TBR=kenrb@chromium.org,creis@chromium.org,alexmos@chromium.org
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=false
> BUG=530663, 339659
>
> Committed: https://crrev.com/8d3be002af4236d2a3cbd9f7687c78f275dcc2f1
> Cr-Commit-Position: refs/heads/master@{#357086}

TBR=kenrb@chromium.org,creis@chromium.org,perkj@chromium.org
BUG=530663, 339659
Committed: https://crrev.com/c4d183e075d2764ff25d1f3aee17c55acc134fba
Cr-Commit-Position: refs/heads/master@{#358207}

[alexmos, 2015-11-05 19:02:44]

Created Reland of OOPIF: Route keyboard events to focused frame in the browser
process.

[alexmos, 2015-11-05 19:03:11]

Description was changed from

==========
Reland of OOPIF: Route keyboard events to focused frame in the browser process.
(patchset #1 id:1 of https://codereview.chromium.org/1407173005/ )

Reason for revert:
The flakiness in SitePerProcessBrowserTest.SubframeKeyboardEventRouting should
now be fixed.  I suspect the issue was that without knowing which remote frame
was focused, the page was setting the main frame as focused frame when the whole
window lost/gained focus (e.g., via alt-tab).  With
https://codereview.chromium.org/1423053002/, we now know propagate which remote
frames are focused, so this shouldn't happen anymore.

Original issue's description:
> Revert of OOPIF: Route keyboard events to focused frame in the browser
process. (patchset #11 id:200001 of https://codereview.chromium.org/1405293002/
)
> 
> Reason for revert:
> SitePerProcessBrowserTest.SubframeKeyboardEventRouting is flaky on Windows 7.
> 
>
http://test-results.appspot.com/dashboards/flakiness_dashboard.html#testType=...
> 
>
http://build.chromium.org/p/chromium.win/builders/Win7%20Tests%20%281%29/buil...
> 
> Original issue's description:
> > OOPIF: Route keyboard events to focused frame in the browser process.
> >
> > Previously, keyboard events were always routed to the top frame's
> > RenderWidgetHost.  With OOPIF, the top frame then forwarded the event
> > to an appropriate subframe renderer if needed.  The extra hop is
> > inefficient and leaks information; moreover, the forwarding broke when
> > mouse event hit-testing in the browser process was introduced.
> >
> > This CL adds logic to send keyboard events directly to the right
> > RenderWidgetHost in the browser process, using the currently focused
> > frame which is already tracked in each FrameTree.  This should be
> > supported for Aura, Mac, and Android.
> >
> > BUG=530663, 339659
> >
> > Committed: https://crrev.com/e2a1799925ea027bd71ea9367280ddfb4403987a
> > Cr-Commit-Position: refs/heads/master@{#357011}
> 
> TBR=kenrb@chromium.org,creis@chromium.org,alexmos@chromium.org
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=false
> BUG=530663, 339659
> 
> Committed: https://crrev.com/8d3be002af4236d2a3cbd9f7687c78f275dcc2f1
> Cr-Commit-Position: refs/heads/master@{#357086}

TBR=kenrb@chromium.org,creis@chromium.org,perkj@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=530663, 339659
==========

to

==========
Reland of OOPIF: Route keyboard events to focused frame in the browser process.
(patchset #1 id:1 of https://codereview.chromium.org/1407173005/ )

Reason for revert:
The flakiness in SitePerProcessBrowserTest.SubframeKeyboardEventRouting should
now be fixed.  I suspect the issue was that without knowing which remote frame
was focused, the page was setting the main frame as focused frame when the whole
window lost/gained focus (e.g., via alt-tab).  With
https://codereview.chromium.org/1423053002/, we now know propagate which remote
frames are focused, so this shouldn't happen anymore.

Original issue's description:
> Revert of OOPIF: Route keyboard events to focused frame in the browser
process. (patchset #11 id:200001 of https://codereview.chromium.org/1405293002/
)
> 
> Reason for revert:
> SitePerProcessBrowserTest.SubframeKeyboardEventRouting is flaky on Windows 7.
> 
>
http://test-results.appspot.com/dashboards/flakiness_dashboard.html#testType=...
> 
>
http://build.chromium.org/p/chromium.win/builders/Win7%20Tests%20%281%29/buil...
> 
> Original issue's description:
> > OOPIF: Route keyboard events to focused frame in the browser process.
> >
> > Previously, keyboard events were always routed to the top frame's
> > RenderWidgetHost.  With OOPIF, the top frame then forwarded the event
> > to an appropriate subframe renderer if needed.  The extra hop is
> > inefficient and leaks information; moreover, the forwarding broke when
> > mouse event hit-testing in the browser process was introduced.
> >
> > This CL adds logic to send keyboard events directly to the right
> > RenderWidgetHost in the browser process, using the currently focused
> > frame which is already tracked in each FrameTree.  This should be
> > supported for Aura, Mac, and Android.
> >
> > BUG=530663, 339659
> >
> > Committed: https://crrev.com/e2a1799925ea027bd71ea9367280ddfb4403987a
> > Cr-Commit-Position: refs/heads/master@{#357011}
> 
> TBR=kenrb@chromium.org,creis@chromium.org,alexmos@chromium.org
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=false
> BUG=530663, 339659
> 
> Committed: https://crrev.com/8d3be002af4236d2a3cbd9f7687c78f275dcc2f1
> Cr-Commit-Position: refs/heads/master@{#357086}

TBR=kenrb@chromium.org,creis@chromium.org,perkj@chromium.org
BUG=530663, 339659
==========

[alexmos, 2015-11-05 19:03:24]

The CQ bit was checked by alexmos@chromium.org

[commit-bot: I haz the power, 2015-11-05 19:04:17]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1413123009/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1413123009/1

[commit-bot: I haz the power, 2015-11-05 19:38:49]

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

[commit-bot: I haz the power, 2015-11-05 19:38:50]

Try jobs failed on following builders:
  win_chromium_rel_ng on tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[alexmos, 2015-11-05 20:19:55]

The CQ bit was checked by alexmos@chromium.org

[commit-bot: I haz the power, 2015-11-05 20:20:36]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1413123009/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1413123009/1

[commit-bot: I haz the power, 2015-11-05 23:01:03]

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

[commit-bot: I haz the power, 2015-11-05 23:01:05]

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

[alexmos, 2015-11-06 00:39:55]

The CQ bit was checked by alexmos@chromium.org

[commit-bot: I haz the power, 2015-11-06 00:41:14]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1413123009/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1413123009/1

[commit-bot: I haz the power, 2015-11-06 00:47:02]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2015-11-06 00:47:56]

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