Paste popup is positioning properly during content scroll.

content/browser/renderer_host/input/touch_selection_controller.cc

Index: content/browser/renderer_host/input/touch_selection_controller.cc
diff --git a/content/browser/renderer_host/input/touch_selection_controller.cc b/content/browser/renderer_host/input/touch_selection_controller.cc
index a7ebb4f429619dc943d55a4e838eed3a90b564a8..292be42a297e776a391410dea94998f192dfaa72 100644
--- a/content/browser/renderer_host/input/touch_selection_controller.cc
+++ b/content/browser/renderer_host/input/touch_selection_controller.cc
@@ -86,7 +86,11 @@ void TouchSelectionController::OnSelectionBoundsChanged(
     return;
   }
 
+  InputEventType last_input_event = last_input_event_type_;
   HideAndDisallowShowingAutomatically();
+  // We need to show insertion handle when we do long press on edit field
+  if (last_input_event == LONG_PRESS)
+    ShowInsertionHandleAutomatically();

[jdduke (slow), 2014/08/04 14:34:58]

I still don't understand this logic, is this because the insertion notification
is coming after the |OnSelectionEditable| call? If the user long presses, we
already call | ShowInsertionHandleAutomatically();|, so it seems like adding
such a call here is hiding some bugs (or creating new ones).

[AKVT, 2014/08/05 14:07:40]

@jdduke
Here the issue is when we long press on an empty edit field as in google.com
page, the ContextMenu (Paste Popup in case it's empty field) is getting
triggered from blink side with proper position, but during the positioning, page
is automatically scrolled, so the position send by engine goes irrelevant. Since
we get onSelectionBoundsChanged() first time without having selection or
insertion, it clears the state of activate_selection_automatically_ and
activate_selection_automatically_ by calling
HideAndDisallowShowingAutomatically(). This prevents falling back to the
required call of 
if (start_orientation_ == TOUCH_HANDLE_CENTER && selection_editable_) {
    OnInsertionChanged();
    return;
}
Even though Selection Editable comes true in later case. So to avoid that I have
added this condition. Ultimately in this scenario to position the Paste Popup
correctly, we need insertion Handle to be shown, so that we can adjust the
position of Popup based on insertion handle position.
Please suggest your opinion, so that we can keep more optimized clean code.
Note: It would be good if we can communicate over IRC, interactively, than
spamming codereview emails to make clear understanding on both sides faster.

[jdduke (slow), 2014/08/05 16:30:43]

I have a workaround here, https://codereview.chromium.org/447493002/. This
change should no longer be necessary.

[AKVT, 2014/08/07 12:01:22]

Thanks. I have rebased the patch according to latest code and verified the
changes.

 }
 
 bool TouchSelectionController::WillHandleTouchEvent(
@@ -183,8 +187,10 @@ bool TouchSelectionController::Animate(base::TimeTicks frame_time) {
 }
 
 void TouchSelectionController::OnHandleDragBegin(const TouchHandle& handle) {
-  if (&handle == insertion_handle_.get())
+  if (&handle == insertion_handle_.get()) {
+    client_->OnSelectionEvent(INSERTION_DRAG_STARTED, GetStartPosition());
     return;
+  }
 
   if (&handle == start_selection_handle_.get()) {
     fixed_handle_position_ = end_selection_handle_->position() -