Unable to reproduce this issue on reported version 62.0.3202.94 using Mac 10.12.6 with steps mentioned in comment#0.

1. Navigated to  https://output.jsbin.com/paqehim/quiet.
2. Placed mouse after the word "select" , Clicked and dragged *upwards*.
3. Now immediately typed "asdf" and observed "asdf" only.

@Reporter: Could you please check the video and let us know if we miss anything. This would help in further triaging of the issue.

Thanks!

Attaching screencast for reference..

Deleted: 786599.mp4 642 KB

	786599.mp4 642 KB View Download

Thanks for looking at this.  I believe the screencast in comment #3 doesn't repro the issue because the mouse is moved to the left while dragging, instead of upwards.  Attached is a recording with the mouse moving upwards, that demonstrates the issue.

Deleted: recording.webm 372 KB

	recording.webm 372 KB View Download

Thank you for providing more feedback. Adding requester "sc00335628@techmahindra.com" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

You can reproduce this with the following steps:

1. Open https://output.jsbin.com/paqehim/quiet
2. Put the mouse inside the text field just after the word "select"
3. Click and drag *upwards* until the word "select" is highlighted
4. with the mouse depressed, type "asdf" at normal speed

The contents of the textfield get replaced with "fdsa". This occurs back to M51.

FYI, I ran a bisect and it seems this has always been broken, but somewhere in this range the failure mode changed:

  https://chromium.googlesource.com/chromium/blink/+log/40eeca9..21cb95a
  (probably http://crrev.com/1049233003 or http://crrev.com/1232783002 is responsible)

Before that, each character would replace the entire selection, leaving you with "f".  (This is also the behavior currently seen in Safari.)

(To comment #6 I would just add that this bug does not require the mouse to be depressed *while* the text is typed.  If it did, the behavior would be more defensible, since the drag is continuously updating the selection.  But I can also repro by typing after the mouse button is released.)

Able to reproduce this issue on reported version 62.0.3202.94 , on latest canary 64.0.3274.0 using Mac 10.12.6, Ubuntu 14.04 and Windows 10 with steps mentioned in comment#4.  i.e; On selecting "select" by dragging mouse upwards and typing "asdf" results in "fdsa"

This issue is seen from M50.[50.0.2661.0]. Hence considering this issue as Non-regression and marking as Untriaged.

Observations: 1. Issue is not seen on firefox
2. Only "f" is seen in safari on typing "asdf"

Thanks!

Mark WontFix since it is race condition of mouse release event and keydown event.
Also change to Pri-3, since this is unusual user interaction.

I can reproduce getting "fdsa" by

1. Open https://output.jsbin.com/paqehim/quiet
2. Put the mouse inside the text field just after the word "select"
3. Press mouse left button and drag toward start of "select" == simply drag right to left 
4. Type "asdf" keep pressing mouse left button

 Issue 787864  has been merged into this issue.

I think I'm hitting this because three-finger touchpad drag on OS X fires a delayed mouseup.  There is at least 0.5-1.0 seconds between when I lift my fingers and when WebViewImpl::HandleMouseUp is called.  Not sure if that's a limitation of the touchpad hardware or something else.