Closed Bug 20106 Opened 25 years ago Closed 25 years ago

[DOGFOOD] caret dissapears after some edit operations, especially after return

Categories

(Core :: DOM: Selection, defect, P3)

x86
Linux
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: mozeditor, Assigned: kinmoz)

References

Details

(Whiteboard: [PDT-])

Note: I have only tested this on mac. I suspect it is all platforms, but I don't
know for sure.

Sometimes after hitting return (and sometimes after other operations, like
inserting an hrule) the caret goes away.  If you type, characters appear in the
right place, so selection seems to be set to the correct place in the document.
There is just no caret.

Getting this to happen is inconsistent, but not hard.  Try this:
In the html editor, create a table with multiple cells.  Put the selection in one
of the cells and type.  Hit return and keep typing.  It may or may not happen
then.  If it doesn't, use the arrow keys to move to a different cell and repeat.
It seems to happen more often for me if I arrow key to a cell.  It shouldn't take
more than 4 or 5 tries to get it to happen.  Once it happens, it will then happen
with greater frequency.

I've stepped through the editor rules code that is creating the content and
setting the selection, and it appears to be working properly.  My guess is that
something in the frame code for <br> is sometimes causing a caret not to draw
when the br is the only thing on the line.

note that you can also get this to happen by just putting hrules in an empty
document, but there are no <br>s in that scenario so that may be a different bug.
Summary: caret dissapears after some edit operations, especially after return → [dogfood] caret dissapears after some edit operations, especially after return
Target Milestone: M12
adding dogfood to summary, begging for m12 resolution if possible.  kin, mike,
I'm very open to debugging sessions on my machine if you have trouble reproducing
this.
I've closed out 19130 because I no longer get the extremely bad behavior
described by that bug (selection goes to wrong place, or even selection goes
goodbye forever and you can't type).  Instead I now get the more innocous but
still iritating behavior of the caret disappearing.  Selection itself appears
correct - further typing appears in correct place.

This is a reminder to test the scenarios in bug 19130 when fixing this bug.
Status: NEW → ASSIGNED
Summary: [dogfood] caret dissapears after some edit operations, especially after return → [DOGFOOD] caret dissapears after some edit operations, especially after return
Accepting bug.
Whiteboard: [PDT-]
Putting on PDT- radar due to last comments that this is not as bad today.
I would argue this is PDT+.  My comment referred to my reasons for closing out a
_different_ bug.
Whiteboard: [PDT-]
Taking off PDT- to get this back on radar for re-review by PDT.  Also, comments
from beppe vie mail:

"Kin and I were just discussing this one, the problem is is that the cursor just
"goes away" and you're looking for it and can't tell where you focus is until
you start typing again. He is already working on a fix for it. I would like for
you guys to please make it a PDT+"
Whiteboard: [PDT-]
Setting to PDT- per discussion with Ender team and PDT.
*** Bug 20346 has been marked as a duplicate of this bug. ***
*** Bug 20460 has been marked as a duplicate of this bug. ***
Moving all M12 non-PDT+ bugs to M13 per request from beppe@netscape.com.
Target Milestone: M12 → M13
Blocks: 19090
we need to fix this bug because there is a PDT+ bug that depends
on this bug 16715..I can't verify 16715 until this one is fixed...
This is a problem with nsRangeList not resetting mHint when programmatically
modifying the selection.

Here is how to reproduce the bug reliably:

1. Start with a blank document in the editor.
2. Type something.
3. Use the left arrow key to move the cursor left.
4. Select All (CTRL-A)
5. Type something
6. Hit the return key.

Your caret should now disappear.
Blocks: 20870
Whiteboard: [PDT-] → [PDT-] Fix in hand. Waiting for code review from mjudge@netscape.com.
Here's the fix for the problem. Waiting for a code review from
mjudge@netscape.com.

Index: nsRangeList.cpp
===================================================================
RCS file: /cvsroot/mozilla/layout/base/src/nsRangeList.cpp,v
retrieving revision 1.167
diff -c -r1.167 nsRangeList.cpp
*** nsRangeList.cpp     1999/12/03 09:23:32     1.167
--- nsRangeList.cpp     1999/12/06 15:24:51
***************
*** 1519,1528 ****
    {
      if (aOffset >= 0)
      {
!       if (mHint == HINTLEFT && aOffset >0)//we should back up a little
          result = aNode->ChildAt(aOffset-1, aNode);
!       else
!         result = aNode->ChildAt(aOffset, aNode);
        if (NS_FAILED(result))
          return result;
        if (!aNode) //out of bounds?
--- 1519,1543 ----
    {
      if (aOffset >= 0)
      {
!       if (mHint == HINTLEFT && aOffset > 0)//we should back up a little
          result = aNode->ChildAt(aOffset-1, aNode);
!       else {
!         PRInt32 childCount = 0;
!         PRInt32 offset = aOffset;
!
!         result = aNode->ChildCount(childCount);
!
!         if (NS_FAILED(result))
!           return result;
!
!         if (childCount <= 0)
!           return NS_ERROR_FAILURE;
!
!         if (aOffset >= childCount)
!           offset = childCount - 1;
!
!         result = aNode->ChildAt(offset, aNode);
!       }
        if (NS_FAILED(result))
          return result;
        if (!aNode) //out of bounds?
woohoo!  thanks!
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Whiteboard: [PDT-] Fix in hand. Waiting for code review from mjudge@netscape.com. → [PDT-]
Fix checked in:

    mozilla/layout/base/src/nsRangeList.cpp  revision 1.168

Reviewed by mjudge@netscape.com.

Should appear in the 12/07/99 builds.
Hmmm, QA may not be able to verify this one until the fix for bug #20524 goes
in.
it can be verified on mac and linux, at least.
We should be able to verify on all platforms now. I just checked in the fix for
bug #20524.
[e-mailed joe to ask if he'd like to verify this bug, given its
semi-reproducible nature.]
Status: RESOLVED → REOPENED
OS: All → Linux
Hardware: All → PC
Using kin's steps to reliably reproduce, this looks good on 2000011208 Mac OS
and 2000011108 Win32.

However, it fails on 2000 01/11 10:00 Linux. The caret consistently disappears
when the document is empty of any text, other than when the window first
appears. (to reproduce, just open a new editor window, type in some text, and
then delete it.)

Thus, re-opening in the event that this isn't a different bug reported elsewhere.
Status: REOPENED → RESOLVED
Closed: 25 years ago25 years ago
...this has been fixed since the build that I used for verification. Will verify
using today's optimized build.

Thanks, kin!
Status: RESOLVED → VERIFIED
Okay, *now* verified fixed using this morning's smoketested Linux build.
No longer blocks: 20870
You need to log in before you can comment on or make changes to this bug.