560665 - When having caret browsing turned on, don't pretend that there is a space in the text box if it's empty

Status: RESOLVED WORKSFORME

(Core :: DOM: Selection, defect)

Description

[(no longer active)]

With my patch in bug 560270, we're using a newline character when the text box is empty, for line-height calculation purposes.  Currently, in caret navigation, that appears as a white-space inside empty textboxes before the editor is initialized.

We need to fix that.

Comment 1

[(no longer active)]

Attachment: Patch (v1)

This patch solves a more general problem.  We need to initialize the editor if some random code uses the document's selection object on an uninitialized text box.  This patch implements this behavior.  One such caller is the caret browsing code, there might be others as well inside the tree.

This approach might also be helpful in fixing bug 561293, as well as bug 560670.

This patch is easy to test, but my need to sleep is more than this patch's need for a test!  :-)  I'll write a test and attach it to the bug tomorrow.

Comment 2

[(no longer active)]

Attachment: Patch (v1.1)

A proof of my need to sleep!  I attached the patch without qrefreshing!

Comment 3

[(no longer active)]

Attachment: Patch (v1.2)

Hmm, nsISelection2.h is not needed.

Comment 4

[Robert O'Callahan (:roc) (email my personal email if necessary)]

+nsEditorInitializerOnSelection::NotifySelectionChanged(nsIDOMDocument* aDoc, nsISelection* aSel, PRInt16 aReason)

80 columns

How do we ensure that mFrame in the listener isn't a dangling pointer? Can we null out mFrame in nsEditorInitializerOnSelection::Destroy and call nsEditorInitializerOnSelection::Destroy from nsTextControlFrame::Destroy?

+  // Make sure that the editor will be initialized when the selection
+  // inside the anonymous content changes.

But you're actually listening on the presShell's selection, right?

It seems like whenever the presshell selection changes, we're going to initialize the editors on all nsTextControlFrames? I must be confused.

Comment 5

[(no longer active)]

I removed the non-breaking space character that was causing this problem in bug 559710 comment 28, so this is no longer an issue.