Steps to reproduce: 1. Open a Bugzilla bug (like this one). 2. Click "reply" to a comment (like this description field). 3. Position the cursor at the end of a line where the next line starts with a '>' character. 4. Hit the right arrow key. Expected results: The cursor should go to the beginning of the next line (to the left of the '>' character). Actual results: The cursor jumps over the '>' character and lands to its right.
Heh David, i keep wondering how you find bugs like this one :)
(In reply to comment #0) > Steps to reproduce: > > 1. Open a Bugzilla bug (like this one). > 2. Click "reply" to a comment (like this description field). > 3. Position the cursor at the end of a line where the next line starts with a > '>' character. > 4. Hit the right arrow key. Actually, you must hit the right arrow key TWICE for the cursor to move. Deleting the '>' characters proves quite challenging as well. I'm guessing this is related.
(In reply to comment #1) > Heh David, i keep wondering how you find bugs like this one :) Just by filing bugs! :) I tend to be very sensitive to the behavior of mouse and keyboard actions, and notice differences very quickly.
Interestingly, if you type your own text with '>' characters, this does not happen. There is something special about what the "reply" function does when pasting text into the textarea. Maybe there's some CR/LF wackiness going on?
Maybe you already know this, but this happened somewhere between the nightlies labeled r14926 and r14941.
(In reply to comment #4) > Interestingly, if you type your own text with '>' characters, this does not > happen. There is something special about what the "reply" function does when > pasting text into the textarea. Maybe there's some CR/LF wackiness going on? Yes, I'm sure this is a CR/LF issue.
(In reply to comment #6) > Yes, I'm sure this is a CR/LF issue. No, I'm wrong. Not a CR/LF issue at all. Instead the issue is that there are actual newline characters in the reply. But when editing we get <br> elements instead. Presumably we always want one or the other. I'm not sure which. Since <br> works right now, my focus should probably be on translating the newlines to <br> elements on the way in, but it also would be good to have editing work properly with actual newline characters in it. I don't see anything in the CSS style sheet or the code that would set the white space mode properly to make the newline characters work, so I really don't know what's going on there.
This boils down to the fact that we use setInnerText, and setInnerText does not turn the newlines into <br> elements. And it should! At least in some whitespace modes.
Created attachment 9028 [details] patch to handle \n and \r in setInnerText -- no test cases or change log
*** Bug 9592 has been marked as a duplicate of this bug. ***
*** Bug 9681 has been marked as a duplicate of this bug. ***
Created attachment 9242 [details] Patch with test case
Comment on attachment 9242 [details] Patch with test case Anders also tested WinIE and found that this matches their behavior.
Committed in r15194