435967 - Caret doesn't move to beginning or ending of div w/ contenteditable = true with repeated left / right arrow keys

Status: NEW

(Core :: DOM: Selection, defect)

Description

[Robbie Paplin]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9) Gecko/2008051206 Firefox/3.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9) Gecko/2008051206 Firefox/3.0

The page listed above has a DIV with a contenteditable = true attribute. The
DIV contains several spans with a contenteditable = false attribute. When I set
the caret to an editable region inside the To field (a/k/a DIV with
contenteditable = true), and repeatedly press the left or right arrow key, the caret doesn't move to beginning or the end of the field like I expect it should.



Reproducible: Always

Steps to Reproduce:
1. Set the caret to a semicolon between names in the To... field
2. Press the left arrow key repeatedly until the caret stops moving
3. Note where the caret stops moving (at the end of the first name, 
4. Set the caret to a semicolon between names in the To... field (like you did
in Step 1)
5. Press the right arrow key repeatedly until the caret stops moving
6. Note where the caret stops moving

Actual Results:  
At step 3, the caret stops moving before it hits the beginning of the
contenteditable DIV. (aka before the first name)

At step 6, the caret stops moving before it hits the end of the
contenteditable DIV. (aka after the last name)

Expected Results:  
At step 3, the caret should stop moving at the beginning of the contenteditable DIV in the left arrow case (aka before the first name / Tom Brady).

At step 6, the caret should stop moving at the ending of the contenteditable DIV in the right arrow case. (aka after the last name / Eli Manning).

The caret should keep moving to the left or right until it is at the beginning or ending of the contenteditable div. After reaching the div boundary, additional left or right arrow key events should be ignored (like a <input type=text> or <textarea> element would act).

The caret should stop moving at the same location after repeated left arrow keys as it does with a Home key.

The caret should stop moving at the same location after repeated right arrow keys as it does with an End key.

Even though, the left/right arrow key stops moving the caret before the begining or ending of the editable region, the caret will still move via the Home key when it's located right after the beginning and will still move via the End key when it's located right before the end.

This bug is related to 423523.

This test case works as expected in MS IE 7.

Comment 1

[Robbie Paplin]

Attachment: Caret inside contenteditable DIV doesn't handle keyboard navigation correctly

Comment 2

[Ryan A. C.]

Seeing this on Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9pre) Gecko/2008052606 Minefield/3.0pre

Comment 3

[Peter Van der Beken [:peterv]]

Attachment: v1

This works, but I'm looking for a better fix.

Comment 4

[Alex Vincent [:WeirdAl]]

Attachment: test_bug435967.html

I've been interested in trying to fix this bug, or at least to get Mozilla Firefox's behavior consistent with Google Chrome's. I tried to write this under web-platform tests, but I couldn't make the test perform the keystrokes in Chrome. That said, opening this HTML attachment in Firefox and in Chrome, and then following the keystrokes, will give an idea, I hope.

I think the nsFrameSelection code is similar to the original code from 13 years ago, particularly in code comments.

Interestingly enough, when the "x" keystroke happens, Google Chrome inserts a new text node under the <div id="editor-inner"> element. Firefox changes the "bar" to "barx".

If there is a way to write this test for web-platform tests, I'd love to see it done.

Comment 5

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

The test expects odd result to me. When ArrowLeft is pressed in the {middleText, 0}, I feel that caret should be put on the end of the previous editable text node.

And you can write the test as WPT like: https://searchfox.org/mozilla-central/source/testing/web-platform/tests/editing/other/typing-around-link-element-at-collapsed-selection.tentative.html

Comment 6

[Alex Vincent [:WeirdAl]]

(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(Got a cold, working slower) from comment #5)

The test expects odd result to me. When ArrowLeft is pressed in the {middleText, 0}, I feel that caret should be put on the end of the previous editable text node.

I think I see a potential trouble spot with that argument, but I'm not sure. (Far more likely is that I don't know what I'm talking about in this next example.) Imagine

<div contenteditable="true">
<span>before</span>
<div>
  <div>
    <div>
      Hello
    </div>
  </div>
</div>
<span>after</span>
</div>

Rendered, the whitespace nodes before and after each <div> and </div> are, well, whitespace - not visible to the user. So from the start of "Hello", to get to the word "before" might take three left keystrokes, for reasons that would be not obvious to the end-user.

I'm not saying you're wrong. I'm just providing an example of funny behavior that might result in if I don't fully understand what you're suggesting. (But that might be the responsibility of the webpage author.)

And you can write the test as WPT like: https://searchfox.org/mozilla-central/source/testing/web-platform/tests/editing/other/typing-around-link-element-at-collapsed-selection.tentative.html

... which fails on all but one test because testdriver.action_sequence returns a Promise.reject(). I appreciate the reference, but I'd need a fix for that before I could use it.