From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2+) Gecko/20010724 BuildID: 2001072403 Reproducible: Always Steps to Reproduce: 1. In a big textbox (more than one line) write something. 2. Press Enter. 3. Type a dot. 4. Press the left arrow once. 5. Press the right arrow once so the cursor gets back were it was after step 3. 6. Press backspace. The cursor will go on the end of the previous line after erasing the dot. 7. Type a dot again. It will appear on the next line.

I did exactly the same I typed 2 lines in this box pressed enter, typed a dot (line 3 now), press the left key, then the right key, then backspace After that the cursor went into the last letter of the second line i typed a dot, and it went into line #3 again So, if that's a bug, then confirmed :) 7/21 linux branch

Over to editor. Looks like the cursor is just being shown in the wrong place...

over to anthonyd

--> kin

Looks like it's fixed now... I can't reproduce it anymore.

Oops soooorry im messed up.. Im better go to bed :( Sorry for spam :(

--> pulling this in to mozilla0.9.8 I think this is just a matter of resetting the caret direction from within the editor. Changing summary from: Text bug with CR in textboxes to: RightArrow than Backspace causes Caret to go to previous line.

This still happens.

Hey I noticed something else closely related to this bug: If there is a scrollbar in the text box (because there is too many lines to fit in), pressing the right arrow key at the end of the last line will warp the cursor to the top of the textbox! This won't happen if all lines fit in the text box. Should I open a new bug for this?

I have apatch for this that is HTML-editor-only in bug 97259. I'll look into putting something similar in the text editor.

--> jfrancis

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

tguyot@geocities.com, no need to file another bug about that. See bug 82151.

098

82151 is a selction bug. The caret goes to wrong place in response to arrow key. Tis bug is an editor bug. The caret goes to wrong place in response to deletion (backspace).

pushing off 098 to 099

plussing

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

The same bug happened by DEL key. Steps to reproduce. 1. Type a word "dog". 2. Hit Enter key. 3. Type "." 4. Locate the caret between "o" and "g". 5. Hit Right-arrow key 2 times. Then the caret is in front of ".". 6. Hit DEL key. As the result, the caret is in after "g". It should be on the last empty line. I confirmed on Mozilla 0.9.7/Linux.

Futher test case This does not occure every time, but i expect you have experieced it 1. Type "test<RETURN>test2<RETURN>22<RETURN><RETURN>" 2. Now push the up arrow and sometimes the cursor will jump out again to the beginning of the 3rd column. I think its better if after an empty line the column jumping feature be reset.. But Sometimes this could be useful.. posibly, what does eveyrone else think?

Textarea should do "SetInterlinePosition(PR_TRUE)", or "SetHint(HINTRIGHT)" when delete procedures are executed, I think. Two candidates where we do are nsPlaintextEditor::DeleteSelection() and nsTextEditRules::DidDeleteSelection(). This patch is latter. I welcome any comments.

099 to 1.0; set pri to 1 for these pushed off EB+ bugs

I guess this is ok. I think for plaintext editors it would be equivilent to just always set the interline position to the right. The only problem I worry about here is getting an uber-caret when you are at the end of a text area. But this refused to happen in testing. I don't know why this doesn't happen.

Comment on attachment 68868 [details] [diff] [review] a sample patch r=jfrancis

Comment on attachment 68868 [details] [diff] [review] a sample patch --- nsTextEditRules.cpp.bak Mon Feb 11 16:19:30 2002 +++ nsTextEditRules.cpp Mon Feb 11 17:34:14 2002 @@ -955,6 +955,13 @@ { res = mEditor->DeleteNode(startNode); } + if (NS_FAILED(res)) return res; Move the error check into the previous |if| block, it will prevent res from being checked twice in the case where strLength != 0. + } + // for Bug 92124 I find it more helpful at times to add a brief comment as to why it's necessary for the change I'm making, rather than just citing a bug number. It makes the code easier to understand, and it saves someone who is looking at the code later on, from having to lookup the bug. + nsCOMPtr<nsISelectionPrivate> selPriv = do_QueryInterface(aSelection); + if (selPriv) + { + res = selPriv->SetInterlinePosition(PR_TRUE); } Lose the braces. Have you done any testing with Plaintext Mail Compose Replies to see if there is any impact in terms of uber-carets that joe mentions above? Plaintext Mail Compose is a special case text editor, that can contain containers like <pre> and <span>.

I tested on both textarea and plain text mail reply. But uber-carets didn't appear. It seems textarea has at least one node (bogus BR or moz BR) after deletions. So, textarea is OK. I have no idea about plain text mail.

Kin brought up the point of whether this code would also be executed from the html editor - in particular if it would get called from "plaintext" html editors. The short answer is "yes". However, it is not a correctness issue, since such editors will always have nsHTMLEditRules::CheckInterlinePosition() acting after the code in this patch, which will correct the situation if needed. So I think we are ok here.

Comment on attachment 72570 [details] [diff] [review] revised patch sr=kin@netscape.com skamio, thanks for fixing this! Try to keep your comment line lengths to less than 80 chars per line so that they can be read easily in editors on the different platforms. Your comment is good, just break it into 2 lines: + // We prevent the caret from sticking on the left of prior BR (i.e. the end of previous line) after this deletion. Bug 92124

Thanks, kin and jfrancis. I'll send a request for branch approval.

Comment on attachment 73112 [details] [diff] [review] revised patch with 2 lines comments Carrying forward previous reviews; a=roc+moz for trunk

patch landed on trunk

verified in 3/12 build. Thomas, this should be working for you now...REOPEN if its still not.

I found another case of this bug. Try my test case below. I'll post a patch for this.

Try to delete the last line on this test case. This case has no relation with HINTRIGHT. So, all you have to do is to delete the last line with BS or DEL key. The problem of this case comes from the lack of last mozBR.

This patch add a routine to add mozBR if needed.

Comment on attachment 74690 [details] [diff] [review] Proposed patch This code makes almost double duty with nsHTMLEditRules::InsertMozBRIfNeeded(). Could we factorize a little bit ?

I don't think so. nsHTMLEditRules::InsertMozBRIfNeeded() inserts mozBR into an empty node. My routine, nsTextEditRules::AddMozBRIfNeeded(), adds mozBR as the last child of parent node of the empty text node. (Sorry, I did not have any other idea of the name.)

I have opened bug 132133 to track this (new) issue. Reclosing this bug.

verified. REOPEN if there is a problem with the original steps in this bug report.