Opened 11 years ago
Closed 11 years ago
#9938 closed defect (fixed)
dijit.getFocus changes break IE restore caret position.
Reported by: | Jared Jurkiewicz | Owned by: | bill |
---|---|---|---|
Priority: | high | Milestone: | 1.4 |
Component: | Editor | Version: | 1.3.2 |
Keywords: | Cc: | ||
Blocked By: | Blocking: |
Description (last modified by )
dijit.getFocus changes break IE restore caret position.
This can be seen using the new InsertEntity plugin:
http://archive.dojotoolkit.org/nightly/dojotoolkit/dojox/editor/tests/editorInsertEntity.html
Select a position other than the top in the editor, just get a caret with no selected text.
Click the InsertEntity button (The Omega), and then select an entity.
Notice that the entity gets inserted at the document top instead of where the caret was.
This worked up until the refactor of dijit.getFocus, which quit returning bookmarks for collapsed carets. dijit.Editor made use of those bookmarks to restore caret position on IE.
How do you suggest we fix? Am I missing something?
Change History (3)
comment:1 Changed 11 years ago by
Description: | modified (diff) |
---|---|
Milestone: | tbd → 1.4 |
Status: | new → assigned |
comment:2 Changed 11 years ago by
OK, I'll revert the change to moveToBookmark() so that it can properly restore caret position. I didn't realize that Editor was depending on that moveToBookmark() function. The call chain is: InsertEntity --> Editor._restoreSelection() --> moveToBookmark().
I thought that IE would save the iframe's selection/caret position and that no sort of _saveSelection()/_restoreSelection() call would be necessary. But it turns out however that IE does lose caret position when the iframe is blurred via a mouse click... just use test_Editor.html and click another toolbar and then shift-tab back into the editor. The caret position has been lost.
As for why ColorPalette? works, but InsertEntity? doesn't, probably just because the ColorPalette? plugin is doing a execCommand("backgroundColor") which works differently than _insertHtmlImpl(). insertHtmlImpl() does things a bunch of funky stuff like this.document.selection.createRange().
comment:3 Changed 11 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
(In [20220]) The editor depends on moveToBookmark() to restore caret position, so moveToBookmark() can't just do nothing for a collapsed selection.
As for getFocus(), when it returns the previous focus rather than the current focus, it can't correctly report the selection in the previously focused node, so changing it to just return nothing about the selection.
Sorry about that... this must be about [19927]. I'll look into it.
Ideally we'd have some solution that won't cause the scroll-jump problem in #9735 but will still work for the editor problem you described above. Maybe thanks to [19966] I can just revert my change about ignoring collapsed selections.