[Android] Adding Smart GO/NEXT feature in Chrome

content/renderer/render_frame_impl.cc

Index: content/renderer/render_frame_impl.cc
diff --git a/content/renderer/render_frame_impl.cc b/content/renderer/render_frame_impl.cc
index 08a77e2290a517292c0844a5ea6781195b74cf5b..8c585f38c89ae1815703662a6ca8ffd6fb896e55 100644
--- a/content/renderer/render_frame_impl.cc
+++ b/content/renderer/render_frame_impl.cc
@@ -179,6 +179,7 @@
 #include "third_party/WebKit/public/platform/URLConversion.h"
 #include "third_party/WebKit/public/platform/WebCachePolicy.h"
 #include "third_party/WebKit/public/platform/WebData.h"
+#include "third_party/WebKit/public/platform/WebFocusType.h"
 #include "third_party/WebKit/public/platform/WebKeyboardEvent.h"
 #include "third_party/WebKit/public/platform/WebMediaPlayer.h"
 #include "third_party/WebKit/public/platform/WebMediaPlayerSource.h"
@@ -1581,6 +1582,7 @@ bool RenderFrameImpl::OnMessageReceived(const IPC::Message& msg) {
     IPC_MESSAGE_HANDLER(FrameMsg_SetFrameOwnerProperties,
                         OnSetFrameOwnerProperties)
     IPC_MESSAGE_HANDLER(FrameMsg_AdvanceFocus, OnAdvanceFocus)
+    IPC_MESSAGE_HANDLER(FrameMsg_AdvanceFocusInForm, OnAdvanceFocusInForm)
     IPC_MESSAGE_HANDLER(FrameMsg_SetFocusedFrame, OnSetFocusedFrame)
     IPC_MESSAGE_HANDLER(FrameMsg_SetTextTrackSettings,
                         OnTextTrackSettingsChanged)
@@ -2206,6 +2208,13 @@ void RenderFrameImpl::OnAdvanceFocus(blink::WebFocusType type,
       type, source_frame->web_frame(), frame_);
 }
 
+void RenderFrameImpl::OnAdvanceFocusInForm(bool forward) {
+  if (render_view_->webview()->focusedFrame() != frame_)
+    return;

[EhsanK, 2017/04/26 21:31:59]

My suggestion for having this early return (and the concern in WebViewImpl
implementation in the older patch) was based on this scenario:
1- An advance commands is issued by ImeAndroid,
2- Something (e.g., javascript) changes focus frame/element before IPC arrives.
3- Focus might jump to next editable element in a new form.

However, the chances of this scenario happening seems very small and the
consequence does not seem terribly bad. Also, the same issue could happen with
element focus anyway. So I guess it might not be very valuable to have this
early return here. I leave that up to you or other reviewers (sorry I had strong
suggestions for it earlier).

[AKVT, 2017/04/27 15:07:02]

Thanks for your suggestion.

+  frame_->advanceFocusInForm(forward ? blink::WebFocusTypeForward
+                                     : blink::WebFocusTypeBackward);
+}
+
 void RenderFrameImpl::OnSetFocusedFrame() {
   // This uses focusDocumentView rather than setFocusedFrame so that focus/blur
   // events are properly dispatched on any currently focused elements.