gfx text fields are not accepting input

VERIFIED FIXED in M10

Status

()

defect
P1
blocker
VERIFIED FIXED
20 years ago
18 years ago

People

(Reporter: mcafee, Assigned: kinmoz)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

XP, apprunner.
gfx text fields are not accepting input.
The gfx URL bar, in particular, is completely dead.
Severity: normal → blocker
OS: Solaris → All
Priority: P3 → P1
Hardware: Sun → All
Target Milestone: M10
I've heard this is effecting all platforms.  Please look at this asap.
cc beard, who made a change, possibly related, to get the native text fields to
work.
kin is looking into this.
This problem looks alot like what I am seeing when I create a blank editor test
bed window via the browser's "File->New->Blank Window" menu item. This loads
about:blank and attatches an editor to it.

I generated a journal file where I simply typed "abcd" and this is what I got:

selRanges = [ [ [[0, 1, 0, 0],   0], [[0, 1, 0, 0],   0] ] ];
EditorSetSelectionFromOffsets(selRanges);
window.editorShell.InsertText("a");
    // WillBeginBatch: 0
    // DidBeginBatch:  0 (0)
    //   WillDo:   <NULL>
    //   DidDo:    <NULL>(0)
    //   WillDo:   Remove Element:
    //   DidDo:    Remove Element: (0)
    //   WillDo:   <NULL>
    //   DidDo:    <NULL>(0)
    // WillEndBatch:   0
    // DidEndBatch:    0 (0)
selRanges = [ [ [[0],   1], [[0],   1] ] ];
EditorSetSelectionFromOffsets(selRanges);
window.editorShell.InsertText("b");
    // WillBeginBatch: 0
    // DidBeginBatch:  0 (0)
    //   WillDo:   <NULL>
    //   DidDo:    <NULL>(0)
    // WillEndBatch:   0
    // DidEndBatch:    0 (0)
selRanges = [ [ [[0],   2], [[0],   2] ] ];
EditorSetSelectionFromOffsets(selRanges);
window.editorShell.InsertText("c");
    // WillBeginBatch: 0
    // DidBeginBatch:  0 (0)
    //   WillDo:   <NULL>
    //   DidDo:    <NULL>(0)
    // WillEndBatch:   0
    // DidEndBatch:    0 (0)
selRanges = [ [ [[0],   3], [[0],   3] ] ];
EditorSetSelectionFromOffsets(selRanges);
window.editorShell.InsertText("d");
    // WillBeginBatch: 0
    // DidBeginBatch:  0 (0)
    //   WillDo:   <NULL>
    //   DidDo:    <NULL>(0)
    // WillEndBatch:   0
    // DidEndBatch:    0 (0)


The interesting bit this journal file points out is that we are inserting our
text as children of the HTML node, not the body node. The line:

    selRanges = [ [ [[0],   1], [[0],   1] ] ];

says that the cursor is at offset 1 inside of the HTML node. To give you an idea
of what really should be happening, I generated journal file with a blank
document I created by doing a select all and then delete. This should create a
blank document identical to the one created by loading about:blank, but it
doesn't.

selRanges = [ [ [[0, 1, 0, 0],   0], [[0, 1, 0, 0],   0] ] ];
EditorSetSelectionFromOffsets(selRanges);
window.editorShell.InsertText("a");
    // WillBeginBatch: 0
    // DidBeginBatch:  0 (0)
    //   WillDo:   <NULL>
    //   DidDo:    <NULL>(0)
    //   WillDo:   Remove Element:
    //   DidDo:    Remove Element: (0)
    //   WillBeginBatch: 1
    //   DidBeginBatch:  1 (0)
    //     WillDo:   <NULL>
    //     DidDo:    <NULL>(0)
    //     WillDo:   Create Element: special text node tag
    //     DidDo:    Create Element: special text node tag(0)
    //     WillDo:   <NULL>
    //     DidDo:    <NULL>(0)
    //   WillEndBatch:   1
    //   DidEndBatch:    1 (0)
    // WillEndBatch:   0
    // DidEndBatch:    0 (0)
selRanges = [ [ [[0, 1, 0],   1], [[0, 1, 0],   1] ] ];
EditorSetSelectionFromOffsets(selRanges);
window.editorShell.InsertText("b");
    // WillBeginBatch: 0
    // DidBeginBatch:  0 (0)
    //   WillDo:   <NULL>
    //   DidDo:    <NULL>(0)
    // WillEndBatch:   0
    // DidEndBatch:    0 (0)
selRanges = [ [ [[0, 1, 0],   2], [[0, 1, 0],   2] ] ];
EditorSetSelectionFromOffsets(selRanges);
window.editorShell.InsertText("c");
    // WillBeginBatch: 0
    // DidBeginBatch:  0 (0)
    //   WillDo:   <NULL>
    //   DidDo:    <NULL>(0)
    // WillEndBatch:   0
    // DidEndBatch:    0 (0)
selRanges = [ [ [[0, 1, 0],   3], [[0, 1, 0],   3] ] ];
EditorSetSelectionFromOffsets(selRanges);
window.editorShell.InsertText("d");
    // WillBeginBatch: 0
    // DidBeginBatch:  0 (0)
    //   WillDo:   <NULL>
    //   DidDo:    <NULL>(0)
    // WillEndBatch:   0
    // DidEndBatch:    0 (0)
The fix for this problem is to re-enable the ClearSelection() call
in nsTextEditRules::WillInsert() that Joe commented out in revision 1.54 of
nsTextEditRules.cpp.

If we don't clear the selection, the InsertText transaction thinks the selection
is still pointing at the text node inside of the bogus div node we just deleted
from the tree. Not sure why the range gravity code is not correcting this.

Tree is currently red. I have to wait for it to turn green before I can check
in.

Index: nsTextEditRules.cpp
===================================================================
RCS file: /cvsroot/mozilla/editor/base/nsTextEditRules.cpp,v
retrieving revision 1.54
diff -c -r1.54 nsTextEditRules.cpp
*** nsTextEditRules.cpp 1999/09/06 19:45:26     1.54
--- nsTextEditRules.cpp 1999/09/07 22:35:45
***************
*** 220,226 ****
      // there is no longer any legit selection, so clear it.

      // xxx why?  The selection is still legit, it just happens to be in an emp
ty doc
!     //aSelection->ClearSelection();
    }

    return NS_OK;
--- 220,226 ----
      // there is no longer any legit selection, so clear it.

      // xxx why?  The selection is still legit, it just happens to be in an emp
ty doc
!     aSelection->ClearSelection();
    }

    return NS_OK;
Assignee: jfrancis → kin
Reassigning bug to kin@netscape.com
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Fix checked into mozilla/editor/base/nsTextEditRules.cpp revision 1.55.
i found and fixed the dom range gravity bug that was the real problem (in
nsRange.cpp) and restored the WillInsert() code to what I had earlier - ie I
removed the ClearSelection() call again.
mcafee, is this working for you now? thanks!
Status: RESOLVED → VERIFIED
workingforme, verifying.
You need to log in before you can comment on or make changes to this bug.