Implement sequential focus navigation for OOPIF.

Implement sequential focus navigation for OOPIF.

Pressing <tab> or <shift-tab> traverses through all focusable elements
on a page, descending into the content of any frames that it
encounters along the way, including cross-origin frames.  This
behavior is currently broken with out-of-process frames: remote frames
are skipped entirely during focus traversal.  This CL puts in the
initial plumbing to fix this and allow advancing focus across frames
in different processes.

When the search for focusable elements in
FocusController::advanceFocusInDocumentOrder encounters an <iframe>
element for a remote frame, it will instruct that frame to continue
the search in its process via the new AdvanceFocus IPCs.  Once the
frame has finished advancing through its focusable elements, it will
use the same IPCs to transfer the search for focusable elements to its
parent frame.  To allow the parent to resume search from the right
place, the IPCs include the source frame (from which the search is
being transferred).

BUG=341918, 339659
Committed: https://crrev.com/401f0abaadb546a25d35c1a35c4557c30d736e06
Cr-Commit-Position: refs/heads/master@{#363362}

[alexmos, 2015-12-04 08:06:08]

Description was changed from

==========
Implement sequential focus navigation for OOPIF.

BUG=341918,339659
==========

to

==========
Implement sequential focus navigation for OOPIF.

Pressing <tab> or <shift-tab> traverses through all focusable elements
on a page, descending into the content of any frames that it
encounters along the way, including cross-origin frames.  This
behavior is currently broken with out-of-process frames: remote frames
are skipped entirely during focus traversal.  This CL puts in the
initial plumbing to fix this and allow advancing focus across frames
in different processes.

When the search for focusable elements in
FocusController::advanceFocusInDocumentOrder encounters an <iframe>
element for a remote frame, it will instruct that frame to continue
the search in its process via the new AdvanceFocus IPCs.  Once the
frame has finished advancing through its focusable elements, it will
use the same IPCs to transfer the search for focusable elements to its
parent frame.  To allow the parent to resume search from the right
place, the IPCs include the source frame (from which the search is
being transferred).

BUG=341918,339659
==========

[alexmos, 2015-12-04 18:20:36]

alexmos@chromium.org changed reviewers:
+ creis@chromium.org, dcheng@chromium.org

[alexmos, 2015-12-04 18:20:37]

Charlie, Daniel - please take a look.  This would have a couple of follow-up
work items, such as getting https://crbug.com/557319 fixed (which will affect
the plumbing here), setting sourceCapabilities properly during OOPIF focus
transfers, and maybe figuring out how to merge advanceFocus and
advanceFocusAcrossFrames in WebViewImpl.  But it does get the common case for
tab traversal working.  Let me know what you think, and whether this is
something we want to land before the trial.

[Charlie Reis, 2015-12-04 21:44:50]

Nice.  content/ LGTM with nits.

https://codereview.chromium.org/1500873002/diff/40001/content/browser/frame_h...
File content/browser/frame_host/render_frame_proxy_host.cc (right):

https://codereview.chromium.org/1500873002/diff/40001/content/browser/frame_h...
content/browser/frame_host/render_frame_proxy_host.cc:334: RenderFrameHostImpl*
source_rfh =
nit: Add comment:
Translate the source RenderFrameHost in this process to its equivalent
RenderFrameProxyHost in the target process.

(Maybe also mention why we need to include it, i.e., for continuing the
traversal after the target frame finishes.)

https://codereview.chromium.org/1500873002/diff/40001/content/browser/site_pe...
File content/browser/site_per_process_browsertest.cc (right):

https://codereview.chromium.org/1500873002/diff/40001/content/browser/site_pe...
content/browser/site_per_process_browsertest.cc:4093: // Assign a name to each
frame.  This will be sent along in messages from
nit: s/messages/test messages/
(To be clear that that names are not a required part of the IPC message for tab
traversal to work.)

https://codereview.chromium.org/1500873002/diff/40001/content/browser/site_pe...
content/browser/site_per_process_browsertest.cc:4104: // have an <input>, then
two <iframe> elements, then another <input>.
Heh, clever.

https://codereview.chromium.org/1500873002/diff/40001/content/browser/site_pe...
content/browser/site_per_process_browsertest.cc:4127: std::string status;
nit: s/status/reply/?

https://codereview.chromium.org/1500873002/diff/40001/content/common/frame_me...
File content/common/frame_messages.h (right):

https://codereview.chromium.org/1500873002/diff/40001/content/common/frame_me...
content/common/frame_messages.h:48:
IPC_ENUM_TRAITS_MIN_MAX_VALUE(AccessibilityMode,
Do we need to list WebFocusType in this list of enum macros?

https://codereview.chromium.org/1500873002/diff/40001/content/common/frame_me...
content/common/frame_messages.h:1262: // This message is sent for a
RenderFrameProxy when sequential focus navigation
nit: s/for/from/

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

https://codereview.chromium.org/1500873002/diff/40001/content/renderer/render...
content/renderer/render_frame_impl.cc:1810: type, source_frame->web_frame(),
frame_);
Should we null check source_frame?

[alexmos, 2015-12-04 22:21:18]

Thanks!  Comments addressed.  Daniel, would you be able to look at the Blink
side today?

https://codereview.chromium.org/1500873002/diff/40001/content/browser/frame_h...
File content/browser/frame_host/render_frame_proxy_host.cc (right):

https://codereview.chromium.org/1500873002/diff/40001/content/browser/frame_h...
content/browser/frame_host/render_frame_proxy_host.cc:334: RenderFrameHostImpl*
source_rfh =
On 2015/12/04 21:44:50, Charlie Reis wrote:
> nit: Add comment:
> Translate the source RenderFrameHost in this process to its equivalent
> RenderFrameProxyHost in the target process.
> 
> (Maybe also mention why we need to include it, i.e., for continuing the
> traversal after the target frame finishes.)

Done.

https://codereview.chromium.org/1500873002/diff/40001/content/browser/site_pe...
File content/browser/site_per_process_browsertest.cc (right):

https://codereview.chromium.org/1500873002/diff/40001/content/browser/site_pe...
content/browser/site_per_process_browsertest.cc:4093: // Assign a name to each
frame.  This will be sent along in messages from
On 2015/12/04 21:44:50, Charlie Reis wrote:
> nit: s/messages/test messages/
> (To be clear that that names are not a required part of the IPC message for
tab
> traversal to work.)

Done.

https://codereview.chromium.org/1500873002/diff/40001/content/browser/site_pe...
content/browser/site_per_process_browsertest.cc:4127: std::string status;
On 2015/12/04 21:44:50, Charlie Reis wrote:
> nit: s/status/reply/?

Done.

https://codereview.chromium.org/1500873002/diff/40001/content/common/frame_me...
File content/common/frame_messages.h (right):

https://codereview.chromium.org/1500873002/diff/40001/content/common/frame_me...
content/common/frame_messages.h:48:
IPC_ENUM_TRAITS_MIN_MAX_VALUE(AccessibilityMode,
On 2015/12/04 21:44:50, Charlie Reis wrote:
> Do we need to list WebFocusType in this list of enum macros?

Turns out this is already done in browser_plugin_messages.h, and re-declaring it
here gives an error.  I guess I could move the macro to this file - would this
file be a better location for it?

https://codereview.chromium.org/1500873002/diff/40001/content/common/frame_me...
content/common/frame_messages.h:1262: // This message is sent for a
RenderFrameProxy when sequential focus navigation
On 2015/12/04 21:44:50, Charlie Reis wrote:
> nit: s/for/from/

Done.

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

https://codereview.chromium.org/1500873002/diff/40001/content/renderer/render...
content/renderer/render_frame_impl.cc:1810: type, source_frame->web_frame(),
frame_);
On 2015/12/04 21:44:50, Charlie Reis wrote:
> Should we null check source_frame?

Done.  I suppose this is possible with race conditions (source frame being
deleted just as it's shifting focus to another frame).  I just abort the focus
shift for now: we won't be able to resume focus traversal from the right place
if the source frame is gone, so I think it's better to not try to focus
anything, rather than to focus an incorrect element.

[Charlie Reis, 2015-12-04 22:27:04]

https://codereview.chromium.org/1500873002/diff/40001/content/common/frame_me...
File content/common/frame_messages.h (right):

https://codereview.chromium.org/1500873002/diff/40001/content/common/frame_me...
content/common/frame_messages.h:48:
IPC_ENUM_TRAITS_MIN_MAX_VALUE(AccessibilityMode,
On 2015/12/04 22:21:18, alexmos wrote:
> On 2015/12/04 21:44:50, Charlie Reis wrote:
> > Do we need to list WebFocusType in this list of enum macros?
> 
> Turns out this is already done in browser_plugin_messages.h, and re-declaring
it
> here gives an error.  I guess I could move the macro to this file - would this
> file be a better location for it?

Yes, I'm guessing this is the right place for it if that still compiles.

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

https://codereview.chromium.org/1500873002/diff/40001/content/renderer/render...
content/renderer/render_frame_impl.cc:1810: type, source_frame->web_frame(),
frame_);
On 2015/12/04 22:21:18, alexmos wrote:
> On 2015/12/04 21:44:50, Charlie Reis wrote:
> > Should we null check source_frame?
> 
> Done.  I suppose this is possible with race conditions (source frame being
> deleted just as it's shifting focus to another frame).  I just abort the focus
> shift for now: we won't be able to resume focus traversal from the right place
> if the source frame is gone, so I think it's better to not try to focus
> anything, rather than to focus an incorrect element.

Acknowledged.

[alexmos, 2015-12-04 22:33:53]

https://codereview.chromium.org/1500873002/diff/40001/content/common/frame_me...
File content/common/frame_messages.h (right):

https://codereview.chromium.org/1500873002/diff/40001/content/common/frame_me...
content/common/frame_messages.h:48:
IPC_ENUM_TRAITS_MIN_MAX_VALUE(AccessibilityMode,
On 2015/12/04 22:27:04, Charlie Reis wrote:
> On 2015/12/04 22:21:18, alexmos wrote:
> > On 2015/12/04 21:44:50, Charlie Reis wrote:
> > > Do we need to list WebFocusType in this list of enum macros?
> > 
> > Turns out this is already done in browser_plugin_messages.h, and
re-declaring
> it
> > here gives an error.  I guess I could move the macro to this file - would
this
> > file be a better location for it?
> 
> Yes, I'm guessing this is the right place for it if that still compiles.

Yup, still compiles.  Moved.

[dcheng, 2015-12-04 23:11:01]

https://codereview.chromium.org/1500873002/diff/40001/content/browser/frame_h...
File content/browser/frame_host/render_frame_proxy_host.cc (right):

https://codereview.chromium.org/1500873002/diff/40001/content/browser/frame_h...
content/browser/frame_host/render_frame_proxy_host.cc:330: int32
source_routing_id) {
Nit: int32_t

https://codereview.chromium.org/1500873002/diff/40001/content/common/frame_me...
File content/common/frame_messages.h (right):

https://codereview.chromium.org/1500873002/diff/40001/content/common/frame_me...
content/common/frame_messages.h:730: int /* source_routing_id */)
Nit: int32_t. Same for other places that mention routing ID for consistency.

https://codereview.chromium.org/1500873002/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/page/FocusController.cpp (right):

https://codereview.chromium.org/1500873002/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/page/FocusController.cpp:766: return false;
I think we should be able to remove this.

https://codereview.chromium.org/1500873002/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/page/FocusController.cpp:767: element =
findFocusableElementRecursively(type,
FocusNavigationScope::focusNavigationScopeOf(*m_page->deprecatedLocalMainFrame()->document()),
nullptr);
and we can just make this toLocalFrame(m_page->mainFrame()) or something.

https://codereview.chromium.org/1500873002/diff/60001/third_party/WebKit/publ...
File third_party/WebKit/public/web/WebView.h (right):

https://codereview.chromium.org/1500873002/diff/60001/third_party/WebKit/publ...
third_party/WebKit/public/web/WebView.h:197: // Advance the focus from the frame
|from| to the next (or previous,
"next in sequence (determined by WebFocusType)"

[dcheng, 2015-12-04 23:16:37]

https://codereview.chromium.org/1500873002/diff/80001/third_party/WebKit/Sour...
File third_party/WebKit/Source/web/WebViewImpl.cpp (right):

https://codereview.chromium.org/1500873002/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/web/WebViewImpl.cpp:2966: }
Also, another thought (this can wait until a future patch): I think this would
better belong on WebLocalFrame.

[alexmos, 2015-12-05 00:07:45]

Thanks!

https://codereview.chromium.org/1500873002/diff/40001/content/browser/frame_h...
File content/browser/frame_host/render_frame_proxy_host.cc (right):

https://codereview.chromium.org/1500873002/diff/40001/content/browser/frame_h...
content/browser/frame_host/render_frame_proxy_host.cc:330: int32
source_routing_id) {
On 2015/12/04 23:11:01, dcheng wrote:
> Nit: int32_t

Done.

https://codereview.chromium.org/1500873002/diff/40001/content/common/frame_me...
File content/common/frame_messages.h (right):

https://codereview.chromium.org/1500873002/diff/40001/content/common/frame_me...
content/common/frame_messages.h:730: int /* source_routing_id */)
On 2015/12/04 23:11:01, dcheng wrote:
> Nit: int32_t. Same for other places that mention routing ID for consistency.

Done.

https://codereview.chromium.org/1500873002/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/page/FocusController.cpp (right):

https://codereview.chromium.org/1500873002/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/page/FocusController.cpp:766: return false;
On 2015/12/04 23:11:01, dcheng wrote:
> I think we should be able to remove this.

Done.  Indeed, focus wrapping to Chrome should only ever happen from the main
frame's process.  Good catch!

https://codereview.chromium.org/1500873002/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/page/FocusController.cpp:767: element =
findFocusableElementRecursively(type,
FocusNavigationScope::focusNavigationScopeOf(*m_page->deprecatedLocalMainFrame()->document()),
nullptr);
On 2015/12/04 23:11:01, dcheng wrote:
> and we can just make this toLocalFrame(m_page->mainFrame()) or something.

Done.

https://codereview.chromium.org/1500873002/diff/60001/third_party/WebKit/publ...
File third_party/WebKit/public/web/WebView.h (right):

https://codereview.chromium.org/1500873002/diff/60001/third_party/WebKit/publ...
third_party/WebKit/public/web/WebView.h:197: // Advance the focus from the frame
|from| to the next (or previous,
On 2015/12/04 23:11:01, dcheng wrote:
> "next in sequence (determined by WebFocusType)"

Done.

https://codereview.chromium.org/1500873002/diff/80001/third_party/WebKit/Sour...
File third_party/WebKit/Source/web/WebViewImpl.cpp (right):

https://codereview.chromium.org/1500873002/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/web/WebViewImpl.cpp:2966: }
On 2015/12/04 23:16:37, dcheng wrote:
> Also, another thought (this can wait until a future patch): I think this would
> better belong on WebLocalFrame.

Agreed.  I'll move it in a future patch.

[dcheng, 2015-12-05 00:17:37]

lgtm

[alexmos, 2015-12-05 00:21:21]

The CQ bit was checked by alexmos@chromium.org

[alexmos, 2015-12-05 00:21:22]

The patchset sent to the CQ was uploaded after l-g-t-m from creis@chromium.org
Link to the patchset: https://codereview.chromium.org/1500873002/#ps100001
(title: "Daniel's comments")

[commit-bot: I haz the power, 2015-12-05 00:25:03]

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

[commit-bot: I haz the power, 2015-12-05 02:08:02]

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

[commit-bot: I haz the power, 2015-12-05 02:08:03]

Try jobs failed on following builders:
  win8_chromium_ng on tryserver.chromium.win (JOB_TIMED_OUT, no build URL)
  win_chromium_compile_dbg_ng on tryserver.chromium.win (JOB_TIMED_OUT, no build
URL)
  win_chromium_rel_ng on tryserver.chromium.win (JOB_TIMED_OUT, no build URL)
  win_chromium_x64_rel_ng on tryserver.chromium.win (JOB_TIMED_OUT, no build
URL)

[alexmos, 2015-12-05 02:16:20]

The CQ bit was checked by alexmos@chromium.org

[commit-bot: I haz the power, 2015-12-05 02:19:28]

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

[commit-bot: I haz the power, 2015-12-05 04:23:47]

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

[commit-bot: I haz the power, 2015-12-05 04:23:48]

Try jobs failed on following builders:
  win8_chromium_ng on tryserver.chromium.win (JOB_TIMED_OUT, no build URL)
  win_chromium_compile_dbg_ng on tryserver.chromium.win (JOB_TIMED_OUT, no build
URL)
  win_chromium_rel_ng on tryserver.chromium.win (JOB_TIMED_OUT, no build URL)
  win_chromium_x64_rel_ng on tryserver.chromium.win (JOB_TIMED_OUT, no build
URL)

[Charlie Reis, 2015-12-05 04:31:31]

The CQ bit was checked by creis@chromium.org

[commit-bot: I haz the power, 2015-12-05 04:33:35]

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

[commit-bot: I haz the power, 2015-12-05 06:35:50]

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

[commit-bot: I haz the power, 2015-12-05 06:35:51]

Try jobs failed on following builders:
  win8_chromium_ng on tryserver.chromium.win (JOB_TIMED_OUT, no build URL)
  win_chromium_compile_dbg_ng on tryserver.chromium.win (JOB_TIMED_OUT, no build
URL)
  win_chromium_rel_ng on tryserver.chromium.win (JOB_TIMED_OUT, no build URL)
  win_chromium_x64_rel_ng on tryserver.chromium.win (JOB_TIMED_OUT, no build
URL)

[alexmos, 2015-12-05 06:48:31]

The CQ bit was checked by alexmos@chromium.org

[commit-bot: I haz the power, 2015-12-05 06:49:04]

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

[commit-bot: I haz the power, 2015-12-05 08:51:12]

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

[commit-bot: I haz the power, 2015-12-05 08:51:13]

Try jobs failed on following builders:
  win8_chromium_ng on tryserver.chromium.win (JOB_TIMED_OUT, no build URL)
  win_chromium_compile_dbg_ng on tryserver.chromium.win (JOB_TIMED_OUT, no build
URL)
  win_chromium_rel_ng on tryserver.chromium.win (JOB_TIMED_OUT, no build URL)
  win_chromium_x64_rel_ng on tryserver.chromium.win (JOB_TIMED_OUT, no build
URL)

[alexmos, 2015-12-05 15:27:45]

The CQ bit was checked by alexmos@chromium.org

[commit-bot: I haz the power, 2015-12-05 15:28:51]

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

[commit-bot: I haz the power, 2015-12-05 17:31:05]

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

[commit-bot: I haz the power, 2015-12-05 17:31:06]

Try jobs failed on following builders:
  win8_chromium_ng on tryserver.chromium.win (JOB_TIMED_OUT, no build URL)
  win_chromium_compile_dbg_ng on tryserver.chromium.win (JOB_TIMED_OUT, no build
URL)
  win_chromium_rel_ng on tryserver.chromium.win (JOB_TIMED_OUT, no build URL)
  win_chromium_x64_rel_ng on tryserver.chromium.win (JOB_TIMED_OUT, no build
URL)

[alexmos, 2015-12-05 23:03:48]

The CQ bit was checked by alexmos@chromium.org

[commit-bot: I haz the power, 2015-12-05 23:04:06]

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

[commit-bot: I haz the power, 2015-12-06 00:07:36]

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

[commit-bot: I haz the power, 2015-12-06 00:07:36]

Exceeded global retry quota

[tandrii(chromium), 2015-12-06 00:14:13]

The CQ bit was checked by tandrii@chromium.org

[commit-bot: I haz the power, 2015-12-06 00:14:56]

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

[commit-bot: I haz the power, 2015-12-06 01:05:28]

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

[commit-bot: I haz the power, 2015-12-06 01:05:30]

Exceeded global retry quota

[tandrii(chromium), 2015-12-06 01:06:38]

The CQ bit was checked by tandrii@chromium.org

[commit-bot: I haz the power, 2015-12-06 01:07:54]

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

[commit-bot: I haz the power, 2015-12-06 01:41:56]

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

[commit-bot: I haz the power, 2015-12-06 01:41:57]

Exceeded global retry quota

[tandrii(chromium), 2015-12-06 01:42:31]

The CQ bit was checked by tandrii@chromium.org

[commit-bot: I haz the power, 2015-12-06 01:42:49]

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

[commit-bot: I haz the power, 2015-12-06 02:33:24]

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

[commit-bot: I haz the power, 2015-12-06 02:33:25]

Exceeded global retry quota

[Charlie Reis, 2015-12-06 07:10:59]

The CQ bit was checked by creis@chromium.org

[commit-bot: I haz the power, 2015-12-06 07:11:09]

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

[commit-bot: I haz the power, 2015-12-06 10:07:50]

Committed patchset #6 (id:100001)

[commit-bot: I haz the power, 2015-12-06 10:09:33]

Description was changed from

==========
Implement sequential focus navigation for OOPIF.

Pressing <tab> or <shift-tab> traverses through all focusable elements
on a page, descending into the content of any frames that it
encounters along the way, including cross-origin frames.  This
behavior is currently broken with out-of-process frames: remote frames
are skipped entirely during focus traversal.  This CL puts in the
initial plumbing to fix this and allow advancing focus across frames
in different processes.

When the search for focusable elements in
FocusController::advanceFocusInDocumentOrder encounters an <iframe>
element for a remote frame, it will instruct that frame to continue
the search in its process via the new AdvanceFocus IPCs.  Once the
frame has finished advancing through its focusable elements, it will
use the same IPCs to transfer the search for focusable elements to its
parent frame.  To allow the parent to resume search from the right
place, the IPCs include the source frame (from which the search is
being transferred).

BUG=341918,339659
==========

to

==========
Implement sequential focus navigation for OOPIF.

Pressing <tab> or <shift-tab> traverses through all focusable elements
on a page, descending into the content of any frames that it
encounters along the way, including cross-origin frames.  This
behavior is currently broken with out-of-process frames: remote frames
are skipped entirely during focus traversal.  This CL puts in the
initial plumbing to fix this and allow advancing focus across frames
in different processes.

When the search for focusable elements in
FocusController::advanceFocusInDocumentOrder encounters an <iframe>
element for a remote frame, it will instruct that frame to continue
the search in its process via the new AdvanceFocus IPCs.  Once the
frame has finished advancing through its focusable elements, it will
use the same IPCs to transfer the search for focusable elements to its
parent frame.  To allow the parent to resume search from the right
place, the IPCs include the source frame (from which the search is
being transferred).

BUG=341918,339659

Committed: https://crrev.com/401f0abaadb546a25d35c1a35c4557c30d736e06
Cr-Commit-Position: refs/heads/master@{#363362}
==========

[commit-bot: I haz the power, 2015-12-06 10:09:34]

Patchset 6 (id:??) landed as
https://crrev.com/401f0abaadb546a25d35c1a35c4557c30d736e06
Cr-Commit-Position: refs/heads/master@{#363362}