Changes between Initial Version and Version 1 of Ticket #11104, comment 13
- Timestamp:
- Feb 17, 2014, 9:37:52 AM (10 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #11104, comment 13
initial v1 11 11 9. `hideSelection` has to move selection to the hidden selection container. We cannot skip that even if selection is locked, because we'll not avoid issue explained in git:f0c7b424 which actually occurs also on IEs (vide this issue). 12 12 10. So `hideSelection` calls `editor.getSelection().selectRanges( [ hiddenSelConRange ] )`. Since editor returns locked selection, `sel#getRanges` falls into the special condition for `sel#isLocked`. This code is a hack, but the only possible hack allowing to play with locked selection and assuring that all other properties of it will be updated accordingly. Unfortunately it is far from perfect and when trying to handle focus it actually fires many focus/blur events what leads locking selection again and... nvmnd :D. Horror. 13 11. But what's also wrong is that to move selection to hidden container `hideSelection` uses locked selection when it should use the real one. This is proposed in [https://github.com/cksource/ckeditor-dev/tree/t/111 40 t/11140].13 11. But what's also wrong is that to move selection to hidden container `hideSelection` uses locked selection when it should use the real one. This is proposed in [https://github.com/cksource/ckeditor-dev/tree/t/11104 t/11104]. 14 14 12. **Hooooowever**, the special condition in `selectRanges` assures that focus gets back to the place where it was originally. Since this code was the actual source of issue, we cannot use it and, since we don't have unlimited time, I want to leave this broken. No one should play with locked selection and I'm for removing the special condition from `selectRanges` in the future. But for now - we can just ignore this.
