UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/58.0.3029.110 Chrome/58.0.3029.110 Safari/537.36

Steps to reproduce the problem:
1. Enter some text, then several carriage returns in a textarea and take note of the selectionStart value for the text area. At this point its value is correct, as in the index of the character that follows the input cursor.
2. Focus another element.
3. Check the value of the selectionStart of the textarea, now it does not include the carriage returns in determining the caret's position.
4. Focus the text area by clicking anywhere within it. The selectionStart value is now 0.

What is the expected behavior?
The selectionStart should remain consistent regardless of the textarea's focus state. In Step 2, the selectionStart should have remained correct. In Step 4, the selectionStart should have a value based on the caret's current position.

What went wrong?
The selectionStart's value is inconsistent. On blur, the selectionStart appears to disregard trailing carriage returns. On focus, the selectionStart is always 0. The value 

Did this work before? Yes 57.0.2987

Does this work in other browsers? Yes

Chrome version: 58.0.3029.110  Channel: stable
OS Version: 
Flash Version: Shockwave Flash 25.0 r0

The selectionStart's value is properly reported in Firefox 53.0.2 as well as Chrome 57.0.2987. I believe older point release of Chrome 58 did not suffer from the issue as well, because our users only began reporting in the last two weeks.

If the caret is repositioned following the carriage returns using the arrow keys, the value is correct when the textarea's focus is lost.
 

Deleted: selectionStartFocusBug.html 815 bytes

selectionStartFocusBug.html 815 bytes View Download