gfx text fields are not accepting input

VERIFIED FIXED in M10

Status

()

P1
blocker
VERIFIED FIXED
19 years ago
17 years ago

People

(Reporter: mcafee, Assigned: kinmoz)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

19 years ago
XP, apprunner.
gfx text fields are not accepting input.
The gfx URL bar, in particular, is completely dead.

Updated

19 years ago
Severity: normal → blocker
OS: Solaris → All
Priority: P3 → P1
Hardware: Sun → All
Target Milestone: M10

Comment 1

19 years ago
I've heard this is effecting all platforms.  Please look at this asap.

Comment 2

19 years ago
cc beard, who made a change, possibly related, to get the native text fields to
work.

Comment 3

19 years ago
kin is looking into this.
(Assignee)

Comment 4

19 years ago
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)
(Assignee)

Comment 5

19 years ago
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)

Updated

19 years ago
Assignee: jfrancis → kin
(Assignee)

Comment 6

19 years ago
Reassigning bug to kin@netscape.com
(Assignee)

Updated

19 years ago
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
(Assignee)

Comment 7

19 years ago
Fix checked into mozilla/editor/base/nsTextEditRules.cpp revision 1.55.

Comment 8

19 years ago
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.

Comment 9

19 years ago
mcafee, is this working for you now? thanks!
(Reporter)

Updated

19 years ago
Status: RESOLVED → VERIFIED
(Reporter)

Comment 10

19 years ago
workingforme, verifying.
You need to log in before you can comment on or make changes to this bug.