I don't recall the specifics of this problem. Joe, I think you proposed it, can you please add some detail? I think it had to do with trying to get a caret at the end of a document: select-all, del, type 1 char, return, problem. Currently, the infinite loop in insert break problem is keeping me from trying this.

To reproduce the problem, do this: 1. Select all, delete 2. Type a line, hit return. You get the big caret on the left. Typing makes a new line. I looked at this yesterday, and I think Joe and I will have to come up with some scheme to keep a bogus text node at the end of the doc in this situation.

M11

This is still a big open issue, for which we have no solution yet. The problem is that if the selection is at the end of the document, hitting return enters a <br> at the end of the line, but does not add any white space (new blank line) to type into, or to put the caret at. This same problem occurs in table cells too.

Here's a thought: Since this is a caret imaging issue, and not a content issue, I assume what we need is a frame to image the caret into, and not necessarily a piece of fake content to change selection. If this assumption is right, then a pseudo-frame might do the trick. Layout supports frames that do not map to any content, as well as multiple frames that map to the same piece of content. I wonder if we can detect the end-of-document (and table cell) case and create a pseudo-frame just for the purpose of giving us the extra line needed to image the caret into. Maybe it's a moz_ style property? cc'ing peter, who is wise about such things.

This is not just a caret issue. We need extra vertical space provided by a blank "line" at the bottom so that the document, or table cell, grows vertically to provide space to type into.

You could try using a ":after" pseudo element on say the body: body:after { content: " " } But since generated content doesn't generally play with selection I'm not sure it this will do what you want...

*** Bug 14069 has been marked as a duplicate of this bug. ***

Reassigning this, due to current focus on performance issues.

I'm not sure that I'm the right person to own this. I dont have a clean solution to this problem from a dom manipulation point of view (which I believe is the thinking behind passing this bug on to me). I think we may need to solve this either with CSS or with some extra smarts in the editor. I certainly can't do anything about it M11... Assigning to buster for further disposition. Give it back to me if you think I should have it anyway. cc'ing simon, Mr Caret.

Putting on [PDT]+ radar.

sent a note to editor group to get a discussion on this going, will move discussion to editor newsgroup.

*** Bug 16888 has been marked as a duplicate of this bug. ***

was not able to get to this before M11 closed, moving to M12.

Assigning to kin@netscape.com

Accepting bug.

setting estimated fix date to 12/10, Kin adjust the date to 12/3 if you think you can get it fixed sooner.

Woo hoo ... jfrancis@netscape.com (Editor Rules God) checked in a fix for this over the thanksgiving break. There are still problems with the caret failing to render when you hit return at the end of a line (bug #20106) so it might not be so apparent that this bug is actually fixed. If you click somewhere else in the document and then back on the blank line, the cursor should reappear.

verified in 11/29 build.

*** Bug 19324 has been marked as a duplicate of this bug. ***