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.

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.

Accepting bug.

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.

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+"

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.

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.

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!

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.]

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.

...this has been fixed since the build that I used for verification. Will verify using today's optimized build. Thanks, kin!

Okay, *now* verified fixed using this morning's smoketested Linux build.