Issue metadata
Sign in to add a comment
|
Selection relocation should be compatible with Range relocation
Reported by
mari...@gmail.com,
Oct 18 2017
|
||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36 Steps to reproduce the problem: 1. Put the selection at the end of editable paragraph with a single text node. Make sure it points into the paragraph, not the text node. 2. Insert a second DOM node at the start of the paragraph. 3. Inspect getSelection().anchorNode and getSelection().anchorOffset, compare to where the cursor is shown. What is the expected behavior? The selection reported by getSelection matches the selection that the user sees. What went wrong? The selection reported by the JavaScript API claims that the cursor is at the end of the paragraph. The blinking cursor shows in the middle of the paragraph (between the two nodes). Typing text inserts it in the middle as well, so this doesn't appear to be just a problem with the way the cursor is drawn. Did this work before? N/A Does this work in other browsers? Yes Chrome version: 59.0.3071.115 Channel: n/a OS Version: Flash Version:
,
Oct 19 2017
Because of relocation of Selection API is done by Range relocation but *actual* selection, which is in SelectionEditor and used for showing caret, is relocated by different algorithm. We should change SelectionEditor to use same relocation algorithm with Range.
,
Oct 19 2017
|
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by abod...@atlassian.com
, Oct 18 2017