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

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}

[perkj_chrome, 2015-10-30 11:24:43]

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

[perkj_chrome, 2015-10-30 11:25:26]

Description was changed from

==========
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=true
BUG=530663, 339659
==========

to

==========
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
==========

[perkj_chrome, 2015-10-30 11:25:36]

The CQ bit was checked by perkj@chromium.org

[commit-bot: I haz the power, 2015-10-30 11:25:46]

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

[commit-bot: I haz the power, 2015-10-30 12:40:41]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2015-10-30 12:41:16]

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

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

A revert of this CL (patchset #1 id:1) has been created in
https://codereview.chromium.org/1413123009/ by alexmos@chromium.org.

The reason for reverting is: 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..