Closed Bug 418135 Opened 14 years ago Closed 14 years ago

ALT+TAB with contenteditable loses caret position


(Core :: DOM: Editor, defect, P3)






(Reporter: cpearce, Unassigned)



(Keywords: testcase)


(1 file)

Attached file Testcase
If you position the caret anywhere in a contenteditable area, alt+tab to another application, then ALT+TAB back, the caret appears at the start of the editable field, not wherever it was before.

1. Open testcase.
2. Position caret at the somewhere other than before the first character.
3. ALT+TAB to another window/application.
4. ALT+TAB back to the testcase window.

Observed result:
The editable area is focused, and the caret is at the start of the editable area.

Expected result:
The editable area is focused, and the caret is in its previous position.
Keywords: testcase
See also bug 413678 which is related. Getting these focus changes correct is starting to be a pain :-(.
This is probably the editor focus listener clearing the selection on blur. IIRC the problem is that the focus code will always start from the current selection to look for the next element in tab order. So when we start from a selection in a contenteditable element (and there's only one such element in the document) it'll go to the contenteditable element, that is already focussed so it continues to the document and focusses that. Next time around it'll start from the selection again and go to the contenteditable element, which isn't focussed, and focus that. So you'd end up with a loop switching between document and contenteditable element and never be able to escape from the document. This problem doesn't happen with inputs or textareas because they have their own selection separate from the document's selection.
Fixed by the fix for bug 406596.
Closed: 14 years ago
OS: Windows Vista → All
Priority: -- → P3
Hardware: PC → All
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9
Version: unspecified → Trunk
You need to log in before you can comment on or make changes to this bug.