Bug 12920 – Links inserted at the beginning of the document

• Component: HTML Editing
• Status: RESOLVED FIXED

[Justin Garcia]

Login to GoogleDocs or Vox (see 7712 and 10165 for GoogleDocs and Vox login instructions, respectively)
Type a words
Click on the Insert Link button in the toolbar
Fill out the required fields, hit OK

The link is inserted at the beginning of the document.  Doesn't happen with GMail's editor.

[Justin Garcia]

Here's what happens:

When you click on the Insert Link toolbar button, an ajax dialog pops up for link creation and a form field inside it gains focus.  When a form field is focused, no other element on the page can be focused, so the editable region in the page behind the dialog is blurred.  This blows its selection away.  When the user is finished and the dialog closes, the editable subframe becomes first responder, and setSelectionFromNone gives it a caret at its beginning.

Adele, we should obviously continue to blur focused nodes when a new node gains focus, but could we leave an inactive selection inside the old focused node in the special case where the old focused node is in a different document than the new focused node in order to fix this bug?  Eventually, all blurred elements should remember their selections and restore them when they regain focus, like FF, I think.

[Adele Peterson]

I completely agree that we need to be able to restore selection for all editable elements.  We even have some comments in the code about this... (I think in one of the focus() methods).

Right now we have special code to do this just for text fields and textareas (in RenderTextControl).

Who should be in charge of keeping track of the old selection?  An element that's an editable root?  Or documents could keep track of this... which would really only be useful for editors that use editable frames.

[Justin Garcia]

r21467