New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 612729 link

Starred by 2 users

Issue metadata

Status: WontFix
Owner:
Closed: May 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug-Regression



Sign in to add a comment

: Wrong behavior or cursor position

Reported by orit.ha...@sap.com, May 18 2016

Issue description

UserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 Safari/537.36

Steps to reproduce the problem:
1. Open the attached html doc in chrome.
2. Press third button (Set Cursor to End).
3. Press third button (Set Cursor to End) again.
4. Press first button (Set Cursor to Begin). 
5. Press first button (Set Cursor to Begin) again.
6. Press fourth button (Set Cursor to End and refocus).

What is the expected behavior?
The expected behavior of steps 2 and 4 are:
2. After pressing the third button (Set Cursor to End) – DomRef.selectionStart/DomRef.selectionEnd (cursor) gets set to the end of the text and the textArea should scroll to the end.
4. After pressing the first button (Set Cursor to Begin) – DomRef.selectionStart/DomRef.selectionEnd (cursor) gets set to the begin of the text and the textArea should scroll to the beginning.

What went wrong?
The behavior is wrong in the following steps:
2. After pressing the third button (Set Cursor to End) – DomRef.selectionStart/DomRef.selectionEnd (cursor) gets set to the end of the text – but textArea does not scroll accordingly.
4. After pressing the first button (Set Cursor to Begin) – DomRef.selectionStart/DomRef.selectionEnd (cursor) gets set to the begin of the text – but textArea does not scroll accordingly.

Did this work before? Yes 

Chrome version: 50.0.2661.102  Channel: stable
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
Flash Version: Shockwave Flash 21.0 r0

Looks like scrolling to current cursor position after setting DomRef.selectionStart/DomRef.selectionEnd takes place only when refocusing the corresponding DomRef … this was different in former chrome versions as well as FF.
 

Comment 1 by orit.ha...@sap.com, May 18 2016

SetSelectionStartChrome.html
5.0 KB View Download
Components: -Enterprise Blink>HTML
Cc: dk...@chromium.org dskaram@chromium.org
Labels: -Type-Bug DevRel-SAP Type-Bug-Regression
Summary: : Wrong behavior or cursor position (was: DevRel-SAP: Wrong behavior or cursor position)
+Dru, who would be the right person from Blink to look at this? Seems like a regression.

Comment 4 by dk...@chromium.org, May 20 2016

Cc: dtapu...@chromium.org tdres...@chromium.org rbyers@chromium.org
+some input dev folks
Cc: yosin@chromium.org
Components: -Blink>HTML Blink>Editing Blink>HTML>Applet
+yosin
Components: -Blink>HTML>Applet Blink>HTML
Owner: yosin@chromium.org
Status: Assigned (was: Unconfirmed)

Comment 8 by yosin@chromium.org, May 23 2016

Components: -Blink>HTML -Blink>Editing Blink>TextSelection>Caret
Status: WontFix (was: Assigned)
Mark "WontFix", this is expected behavior.

Setting caret position from script doesn't cause scroll, see FrameSelection::setSelectionAlgorithm() and |align| parameter usage.

Since, "Set Cursor to Begin" and "Set Cursor to End" set focus to text area before setting caret position. Element#focus at second click causes re-paint and scroll.

I proposed new API Selection#makeVisible() to solve this issue: see https://github.com/w3c/editing/issues/129

Comment 9 by tkent@chromium.org, Oct 12 2016

Components: Blink>Editing>Selection

Comment 10 by tkent@chromium.org, Oct 12 2016

Components: -Blink>TextSelection>Caret

Sign in to add a comment