SelectionEditor doesn't update SelectionInDOMTree on node insertion
Reported by
p.koszul...@cksource.com,
Jul 7 2017
|
||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36 Steps to reproduce the problem: There are two samples which reproduce a similar issue: * https://jsfiddle.net/szymonkups/nf0d44d9/ * https://jsfiddle.net/szymonkups/eqez6gtb/ In both cases, after some nodes are removed and inserted, the selection is rendered on a different piece of the content than what you can query through the selection API. Basically, it seems that it's rendered only on the first node. What is the expected behavior? The rendered selection should be in sync with what document.getSelection() returns. What went wrong? The rendered selection gets out of sync with what document.getSelection() returns. Did this work before? N/A Does this work in other browsers? Yes Chrome version: 59.0.3071.115 Channel: stable OS Version: OS X 10.12.4 Flash Version: This issue affects CKEditor: https://github.com/ckeditor/ckeditor5-engine/issues/992. I think that this is a quite recent regression because we started noticing issues with this about a month ago.
,
Jul 7 2017
,
Jul 10 2017
This is cause by mismatch of cached Range and SelectionEdtior::selection_
HTML: <p>foo</p>
Selection: seleciton.collaps(P, 0); selection.collapse(P, 1)
Range:
start: container: P, before: null, index: dirty
end: container P, before "foo", index: dirty
SelectionInDOMTree:
base: container: P, offset: 0
extent: container: P, offset: 1
When inserting "bar" before "foo", both Range and SelectionInDOMtree aren't changed.
When accessing cached Range via Selection#{anchor,focus}{Node,Offset}.
We compute indexes of cached Range:
start: container: P, before: null, index: 0
end: container P, before "foo", index: 2
However SelectionEditor::selection_ is still P@0 and P@1.
It seems we should use RangeBoudnaryPostiion, which represents start/end in Range, in
SelectionEdtior.
,
Jul 11 2017
Able to reproduce this issue on Ubuntu 14.04, Windows-10 and Mac OS 10.12.5 using chrome latest stable #59.0.3071.115. This is a non-regression issue seen on chrome older version of M45-45.0.2454.0 as well and observing different behavior on M35-35.0.1849.0 ie. only foo is displayed.
,
Jul 26 2017
What is even more depressing is that "refreshing" selection does not work, too. If selection is collapsed and then extended to the same nodes and offsets, it is not refreshed, so there's no real workaround for this bug. https://jsfiddle.net/hbupm6w8/
,
Oct 19 2017
Issue 775939 has been merged into this issue.
,
Oct 30 2017
,
Jan 10 2018
,
Apr 3 2018
Hi! Any update on this? This issue gives so bad visual output that our users think that something is completely broken on our side (https://github.com/ckeditor/ckeditor5/issues/932).
,
Apr 3 2018
Cause: SelectionEditor isn't listening to node insertion, and hence, doesn't update its stored SelectionInDOMTree for it. While it's listening to ChildrenChanged, this only invalidates selection painting without relocating the SelectionInDOMTree.
,
Apr 4 2018
The ideal solution is http://crbug.com/751387 Unify Position and RangeBoundaryPoint
,
Apr 4 2018
Discussed with yosin@. While the big ideal solution is there which fixes all potential issues like this, there is a local small fix: Make sure that SelectionEditor never store any offset-in-anchor positions with non-text anchor node in its stored SelectionInDOMTree. Whenever it receives such a position, convert it into before/after anchor. zhuoyu.qian@: would you kindly take this? :)
,
Apr 4 2018
OK, I will take this. |
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by manoranj...@chromium.org
, Jul 7 2017