Bug 9528 – REGRESSION: arrow key skips '>' in Bugzilla replies due to '\n' in text nodes

• Status: RESOLVED
• Resolution: FIXED
• Component: Forms

[David Kilzer (:ddkilzer)]

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.

[Joost de Valk (AlthA)]

Heh David, i keep wondering how you find bugs like this one :)

[David Kilzer (:ddkilzer)]

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

[David Kilzer (:ddkilzer)]

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

[David Kilzer (:ddkilzer)]

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.

[Darin Adler]

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

[Darin Adler]

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

[Darin Adler]

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.

[Darin Adler]

Created attachment 9028 [details]
patch to handle \n and \r in setInnerText -- no test cases or change log

[Darin Adler]

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

[David Kilzer (:ddkilzer)]

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

[Anders Carlsson]

Created attachment 9242 [details]
Patch with test case

[Adele Peterson]

Comment on attachment 9242 [details]
Patch with test case

Anders also tested WinIE and found that this matches their behavior.

[Anders Carlsson]

Committed in r15194