393568 - Impossible to enter text in the xbox.com forums editor

Status: RESOLVED FIXED

(Core :: DOM: Editor, defect)

Description

[Martijn Wargers (dead)]

This came from Hendrix feedback:
http://groups.google.com/group/mozilla.feedback/browse_thread/thread/16dc47079b59f033/8859ecadee100020?lnk=st&

It has become impossible to enter text in that designMode iframe on that page.
This regressed between 2007-06-26 and 2007-06-28, regression from bug 237964.
I don't have a minimal testcase yet. However, this might be related/the same as one of the other bugs that block bug 237964.

Comment 1

[Chris Pearce [:cpearce (Not reading bugmail)]]

I was not able to reproduce this using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6 on my XP box. Is anyone else able to reproduce?

Comment 2

[-fullmetaljacket-]

(In reply to comment #1)
> I was not able to reproduce this using Mozilla/5.0 (Windows; U; Windows NT 5.1;
> en-US; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6 on my XP box. Is anyone else
> able to reproduce?
> 
this is a trunk only bug.

Comment 3

[Chris Pearce [:cpearce (Not reading bugmail)]]

You're absolutely right. If I run trunk, and I try to enter some text in the text area in the xbox forums, I get an assertion failure (on every key press):

ASSERTION: bad action nesting!: 'mActionNesting>0', file c:/work/mozilla-trunk/mozilla/editor/libeditor/html/nsHTMLEditRules.cpp, line 385.

I'll take a closer look...

Comment 4

[Chris Pearce [:cpearce (Not reading bugmail)]]

Whenever I click in the text area down the bottom, I get a debug message:

JavaScript error: , line 0: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMNSHTMLDocument.queryCommandValue]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: http://forums.xbox.com/FreeTextBox3/FTB-FreeTextBox.js :: anonymous :: line 744"  data: no]

Comment 5

[Chris Pearce [:cpearce (Not reading bugmail)]]

What is causing the editing to fail, is that the selection has been cleared when we come to nsPlaintextEditor::InsertText(nsAString&) (nsplaintexteditor.cpp:733). Because it's been cleared, the editing has no selection into which to insert text, and it's not inserting it anywhere.

Comment 6

[Chris Pearce [:cpearce (Not reading bugmail)]]

More specifically, the problem is in nsTextEditorFocusListener::Focus(nsIDOMEvent* aEvent), in the call:

  if (selectionPrivate) {
    selectionPrivate->SetAncestorLimiter(editableRoot);
  }

SetAncestorLimiter() is clearing the selection, resulting in nsPlaintextEditor::InsertText(nsAString&) failing later. Commenting out the call to SetAncestorLimiter() makes the bug go away... What's the reason this call is here?

Comment 7

[Martijn Wargers (dead)]

I think it's to limit the selection to a certain area (like for contentEditable nodes), not sure though.
I think it could use some explanation at:
http://lxr.mozilla.org/seamonkey/source/content/base/public/nsISelectionPrivate.idl#120

But that method can also clear the selection in certain circumstances, it seems:
http://lxr.mozilla.org/seamonkey/source/layout/generic/nsSelection.cpp#3864

Thanks for looking into this, Chris.

Comment 8

[Chris Pearce [:cpearce (Not reading bugmail)]]

Attachment: Test case - Free Text Box with editing not working

Test case for bug 393568. This is a cut down version of the xbox.com Free Text Box page, which uses an editable IFrame. To reproduce bug:

* Open 'index.AddPost.aspx.htm' in trunk FF.
* Click on the IFrame, note no caret visible.
* Try to type text, note no text can be entered.

Sometimes after banging around a bit it will accept text, but usually it doesn't work.

Comment 9

[Chris Pearce [:cpearce (Not reading bugmail)]]

The reason that nsFrameSelection::SetAncestorLimiter() is clearing the selection, is that IsValidSelectionPoint(), is being passed mDomSelections[0]->FetchFocusNode(), which is null. Not quite sure why this is...

(Code snippet for convenience...)

void
nsFrameSelection::SetAncestorLimiter(nsIContent *aLimiter)
{
  if (mAncestorLimiter != aLimiter) {
    mAncestorLimiter = aLimiter;
    PRInt8 index =
      GetIndexFromSelectionType(nsISelectionController::SELECTION_NORMAL);
    if (!IsValidSelectionPoint(this, mDomSelections[index]->FetchFocusNode())) {
      ClearNormalSelection();
      if (mAncestorLimiter) {
        PostReason(nsISelectionListener::NO_REASON);
        TakeFocus(mAncestorLimiter, 0, 0, PR_FALSE, PR_FALSE);
      }
    }
  }
}

Comment 10

[Chris Pearce [:cpearce (Not reading bugmail)]]

Further, it looks like the mDomSelections should be initialized by nsFrameSelection::TakeFocus()... However, there's a code block in there preventing it:

 //HACKHACKHACK
 if (!aNewFocus->GetParent())
   return NS_ERROR_FAILURE;
 //END HACKHACKHACK /checking for root frames/content

Call me crazy, but HACKHACKHACK comments make me suspicious... Commenting this out allows the carret to appear in the IFrame, and allows us to enter text, though the carret does first appear near the RHS of the box, about half way up the first line.

Is the HACKHACKHACK there for a good reason?

Comment 11

[Martijn Wargers (dead)]

Bonsai might give some information on that (but in this case it seems useless):
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/generic/nsSelection.cpp&rev=3.294#2397
It seems to me that piece of code says that when aNewFocus isn't in the document, then it shouldn't continue carrying out that code.

Comment 12

[Peter Van der Beken [:peterv]]

Isn't this a duplicate of bug 335856? I think my patch there fixes this testcase too.

Comment 13

[Martijn Wargers (dead)]

Ok, marking dependancy on that bug, then.

Comment 14

[Chris Pearce [:cpearce (Not reading bugmail)]]

Yup, Peter's patch does fix this bug, though the cursor is vertically offset when entering the iframe... Details in bug 335856 comments...

Comment 15

[Peter Van der Beken [:peterv]]

Fixed by the fix for bug 335856. For the issue from comment 14 see bug 395965.