Issue metadata
Sign in to add a comment
|
: Wrong behavior or cursor position
Reported by
orit.ha...@sap.com,
May 18 2016
|
||||||||||||||||||||||
Issue descriptionUserAgent: 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.
,
May 18 2016
,
May 19 2016
+Dru, who would be the right person from Blink to look at this? Seems like a regression.
,
May 20 2016
+some input dev folks
,
May 20 2016
+yosin
,
May 20 2016
,
May 22 2016
,
May 23 2016
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
,
Oct 12 2016
,
Oct 12 2016
|
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by orit.ha...@sap.com
, May 18 20165.0 KB
5.0 KB View Download