Are there any repro steps where an update should be sent but we don't get any? Also I am assuming there are more than one WebFrameWidgets in test case.

You can use my CL at https://codereview.chromium.org/2883653002/ and modify TouchSelectionControllerClientChildFrame::IsCommandIdEnabled() according to the comment contained there. Then grab a touchscreen and try it out.

I can demo it for you if you like.

Is this the reason for stuck text selection in Clank on pages with ads like [1]? After I touch-select in the ad text and then tap outside of the ad frame, the text selected in ad changes highlight from blue to gray but stays selected.

This repros for me in dev 60.0.3107.3 and is fine in stable 58.0.3029.121.

[1] - https://www.washingtonpost.com/news/the-switch/wp/2017/05/26/the-newest-dystopian-setting-in-one-of-gamings-top-franchises-rural-america/?utm_term=.42435c60e7f4

See stuck selection on word "moments" in a screenshot.

Deleted: Screenshot_20170527-095503.png 1.5 MB

	Screenshot_20170527-095503.png 1.5 MB View Download

The gray selected text just indicates that the frame it lives in doesn't have focus. In the OOPIF world, each cross-process frame can have its own selection.

However, beware: Touch-Selection for oopif for Android is still in progress ... we just landed code to enable TSE for oopifs on desktop.

> each cross-process frame can have its own selection
Understand but I have to say, this looks very weird, especially on a phone.

I think the reason this works for main frame is issue 726763 where we fallback to main frame when the focused frame is nullptr. That being said, the reason we have this situation is that in GestureManager::HandleGestureLongPress the code first calls SelectionController::HandleGestureLongPress and then MouseEventManager::FocusDocumentView (which means when we get to SyncSelectionIfRequired, the frame is not yet focused).

Now my question is, are there any cases where the frame which is receiving a gesture should not get focused? It seems like we focus the frame anyway (either by calling MouseEventManager::FocusDocumentView or MouseEventManager::HandleMouseFocus which is called from GestureManager::SendContextMenuEventForGesture).

On a separate note, moving CaretOrSelectionRange() to WebLocalFrame (from WebWidget) fixes this. It also makes sense to make the move since most other selection related methods are in WebLocalFrame.

Assigning it to myself since I have a CL in progress.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/d503ac6073fad15a95d4eb5d9f1343a315c7a9d7

commit d503ac6073fad15a95d4eb5d9f1343a315c7a9d7
Author: ekaramad <ekaramad@chromium.org>
Date: Wed Jul 19 23:26:32 2017

[refactor] - Rename and Move WebWidget::CaretOrSelectionRange to WebInputMethodController::GetSelectionOffsets

Reasons for move:
1- This is a frame concept given (the two nontrivial calls are from
   render_frame_impl.cc and frame_input_handler_impl.cc).

2- It cleans up WebViewImpl/WebFrameWidgetImpl (and helps with the split)

3- The logic is simply calling the corresponding method on
   InputMethodController of the focused LocalFrame.

4- Jumping from RenderFrameImpl to RenderWidget for getting selection is futile
   and expecting a focused frame is incorrect. Note that
   GestureManager::HandleGestureLongPress first passes the hit test result to
   SelectionController and then to MouseEventManager where the former generates
   selection updates and the latter updates frame focus. Therefore, right now,
   long pressing text on an unfocused OOPIF will lead to an empty selection
   update which is incorrect.

Reason for rename:
1- The method calls GetSelectionOffsets on InputMethodController (core) and it
   makes sense to make the wrapper variant have the same name.

  This CL also adds a small change to TextSelectionControllerClientChildFrame
to use selection range instead of selection bounds (now that the update is
fixed after the refactor).

BUG= 629721 ,  723790 

Review-Url: https://codereview.chromium.org/2910223003
Cr-Commit-Position: refs/heads/master@{#488035}

[modify] https://crrev.com/d503ac6073fad15a95d4eb5d9f1343a315c7a9d7/content/browser/renderer_host/input/touch_selection_controller_client_child_frame.cc
[modify] https://crrev.com/d503ac6073fad15a95d4eb5d9f1343a315c7a9d7/content/renderer/input/frame_input_handler_impl.cc
[modify] https://crrev.com/d503ac6073fad15a95d4eb5d9f1343a315c7a9d7/content/renderer/render_frame_impl.cc
[modify] https://crrev.com/d503ac6073fad15a95d4eb5d9f1343a315c7a9d7/third_party/WebKit/Source/core/exported/WebInputMethodControllerImpl.cpp
[modify] https://crrev.com/d503ac6073fad15a95d4eb5d9f1343a315c7a9d7/third_party/WebKit/Source/core/exported/WebInputMethodControllerImpl.h
[modify] https://crrev.com/d503ac6073fad15a95d4eb5d9f1343a315c7a9d7/third_party/WebKit/Source/core/exported/WebViewTest.cpp
[modify] https://crrev.com/d503ac6073fad15a95d4eb5d9f1343a315c7a9d7/third_party/WebKit/Source/core/frame/WebFrameWidgetImpl.cpp
[modify] https://crrev.com/d503ac6073fad15a95d4eb5d9f1343a315c7a9d7/third_party/WebKit/Source/core/frame/WebFrameWidgetImpl.h
[modify] https://crrev.com/d503ac6073fad15a95d4eb5d9f1343a315c7a9d7/third_party/WebKit/Source/core/frame/WebViewFrameWidget.cpp
[modify] https://crrev.com/d503ac6073fad15a95d4eb5d9f1343a315c7a9d7/third_party/WebKit/Source/core/frame/WebViewFrameWidget.h
[modify] https://crrev.com/d503ac6073fad15a95d4eb5d9f1343a315c7a9d7/third_party/WebKit/Source/web/WebViewImpl.cpp
[modify] https://crrev.com/d503ac6073fad15a95d4eb5d9f1343a315c7a9d7/third_party/WebKit/Source/web/WebViewImpl.h
[modify] https://crrev.com/d503ac6073fad15a95d4eb5d9f1343a315c7a9d7/third_party/WebKit/public/web/WebInputMethodController.h
[modify] https://crrev.com/d503ac6073fad15a95d4eb5d9f1343a315c7a9d7/third_party/WebKit/public/web/WebView.h
[modify] https://crrev.com/d503ac6073fad15a95d4eb5d9f1343a315c7a9d7/third_party/WebKit/public/web/WebWidget.h

Marking this bug as fixed based on comment #10.