Thank you  huglovefan1998@, Sorry for rebisecting to make sure we are pointing to right Cl and you are spot one. Please find the bisect below :

You are probably looking for a change made after 450369 (known good), but no lat
er than 450370 (first known bad).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/18375370aff250f59f5ef624ecf686d860377ece..d892f9592860691ae9a782c12260c94ed6bd1a63


issue is reproducible on Windows 7,10, Mac and Linux on latest Chrome Dev, Canary and Stable, Since it's Blink related change tagging Android and ChromeOS 

As 58 is already in stable for these browser platforms, should this really have a ReleaseBlock-Stable label?

We are looking to qualify a Chrome OS stable build tomorrow, so we need to determine quickly the severity of this issue.

#4, I don't think this is a M58 stable blocker.

Reproduced.
This happens when we have:
 1. 2 line breaks on the end of textarea.
 2. Cursor is on the end.
 3. Focus out with mouse/tab.
Then selectionStart/End point after first line break.

 Issue 716327  has been merged into this issue.

This issue can be triggered in another way:
Copy "test\n" to your clipboard.
Now load the test case from the original bug report and focus the textarea and paste it n times using Ctrl-V with n>=2. selectionStart/selectionEnd will now be n*5, which is to be expected.
Now unfocus the textarea by clicking outside of it or pressing tab. It will now show "selectionStart: 5, selectionEnd: 5", which is wrong.

After you followed the steps above, put the focus back on the textarea.
Now press Ctrl-A (or select the whole textarea using your mouse). Now press backspace or delete (this step is important, otherwise it will show 5 again). Press Ctrl-V n times (n>=2). Unfocus the textarea. It will now show "selectionStart: 0, selectionEnd: 0", which is also wrong (but with a different value for some reason).

In any case (including the steps from the original bug report), selectionStart/End stay correct if:
- you click with the mouse on the current cursor position before unfocusing.
- you temporarily change the cursor position e.g. by pressing left and then right arrow key before unfocusing.

Note that this issue does not only affect the selectionStart/End JavaScript properties, but when focusing the textarea by pressing tab again, the cursor will be at the wrong position (the same position as denoted by the JS properties).

Using "Version 58.0.3029.81 Built on Ubuntu , running on Ubuntu 14.04 (64-bit)".

selectionStart and selectionEnd is updated internally by 'selectionchange' event.  It seems that 'selectionchange' event is not dispatched by Enter key, Backspace key, and paste operation.

Does fix for this issue also fix  issue 503132 ?

> It seems that 'selectionchange' event is not dispatched by Enter key, Backspace key, and paste operation.

Because editing Text nodes in a text control are split at the caret position, and DOM representation of the position is not changed.

> Does fix for this issue also fix   issue 503132  ?

I'm not sure what it is.

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

commit e71aa45ab3098edca75725a658d3624f5ed47108
Author: tkent <tkent@chromium.org>
Date: Fri May 12 12:59:21 2017

INPUT/TEXTAREA elements: Fix incorrect selectionStart/selectionEnd values after blur.

We failed to update selectionStart/selectionEnd cache because
TextControlElement::SelectionChanged() is not called in some cases after
crrev.com/450370.

After this CL, selection values are cached in webkitEditableContentChanged event
handling code too.  It is called on every DOM mutation in text control editor.

BUG= 714425 

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

[add] https://crrev.com/e71aa45ab3098edca75725a658d3624f5ed47108/third_party/WebKit/LayoutTests/fast/forms/text-control-selection-after-blur.html
[add] https://crrev.com/e71aa45ab3098edca75725a658d3624f5ed47108/third_party/WebKit/LayoutTests/fast/forms/text/text-selection-after-type-change.html
[modify] https://crrev.com/e71aa45ab3098edca75725a658d3624f5ed47108/third_party/WebKit/Source/core/html/TextControlElement.cpp

Your change meets the bar and is auto-approved for M59. Please go ahead and merge the CL to branch 3071 manually. Please contact milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), gkihumba@(ChromeOS), Abdul Syed@(Desktop)

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

Please merge your change to M59 branch 3071 by 4:00 PM PT, Monday (05/15) so we can take it in for next week beta release. Thank you.

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

commit e05011e0add858f12cb6f90cc534415870d9f7af
Author: Kent Tamura <tkent@chromium.org>
Date: Mon May 15 05:56:31 2017

Merge "INPUT/TEXTAREA elements: Fix incorrect selectionStart/selectionEnd values after blur." to M59

We failed to update selectionStart/selectionEnd cache because
TextControlElement::SelectionChanged() is not called in some cases after
crrev.com/450370.

After this CL, selection values are cached in webkitEditableContentChanged event
handling code too.  It is called on every DOM mutation in text control editor.

BUG= 714425 

Review-Url: https://codereview.chromium.org/2878613002
Cr-Original-Commit-Position: refs/heads/master@{#471290}
Review-Url: https://codereview.chromium.org/2882953002 .
Cr-Commit-Position: refs/branch-heads/3071@{#549}
Cr-Branched-From: a106f0abbf69dad349d4aaf4bcc4f5d376dd2377-refs/heads/master@{#464641}

[add] https://crrev.com/e05011e0add858f12cb6f90cc534415870d9f7af/third_party/WebKit/LayoutTests/fast/forms/text-control-selection-after-blur.html
[add] https://crrev.com/e05011e0add858f12cb6f90cc534415870d9f7af/third_party/WebKit/LayoutTests/fast/forms/text/text-selection-after-type-change.html
[modify] https://crrev.com/e05011e0add858f12cb6f90cc534415870d9f7af/third_party/WebKit/Source/core/html/TextControlElement.cpp

 Issue 721733  has been merged into this issue.

Verified this issue on Mac OS 10.12, Ubuntu 14.04 and Windows-10 using chrome latest beta M59-59.0.3071.61 by following steps mentioned in the original comment. After step-4 observed the selection number stays same as expected. Hence adding TE-Verified label.

Deleted: 714425.ogv 939 KB

	714425.ogv 939 KB View Download

 Issue 724403  has been merged into this issue.

 Issue 725139  has been merged into this issue.

 Issue 727199  has been merged into this issue.

 Issue 726333  has been merged into this issue.

 Issue 730942  has been merged into this issue.

 Issue 734428  has been merged into this issue.