User Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.14 Safari/537.36 Steps to reproduce: On windows platform, open simple html page containing the following content with firefox, <!DOCTYPE html> <html lang="en"> <head> </head> <body> <h2>Content Editable</h2> <div style="width: 500px; height: 250px; border: 1px solid black" contenteditable="true"> This is the first paragraph. (paragraph 1). <br/>This is the second paragraph. (paragraph 2). </div> </body> </html> move the cursor to the end of paragraph 2 and press ctrl+up , similarly move the cursor to the beginning of paragraph 1 and press ctrl+down Actual results: ctrl+up moves cursor to the beginning of line ctrl+down moves cursor to the end of the line Expected results: ctrl+up should move cursor to the beginning of the current paragraph and subsequently to the beginning of each of the previous paragraphs, whilst ctrl+down should always move to the beginning of the next paragraph. For comparison start Word Pad , enter the same paragraph and navigate through the same key combination FYI, this issue is also seen on the latest firefox release, and on firefox nightly as well.
Hi Loic, Do you have any updates for this bug, can you see this gets assigned to someone
Editor bugs are not patched very often, a few people at Mozilla are aware of this code area.
It doesn't depends on content editable. Even if on textarea, this occurs. Although we should calculate the offset includes XP (CRLF vs LF), but nsFrameSelection::MoveCaret don't consider it yet.
Ah, ctrl+down is mapped as cmd_moveDown2 and eSelectEndLine and. So this is correct behavior.
You need to log in before you can comment on or make changes to this bug.