456622 - Caret can "wrap around" inside a contenteditable, RTL element

Status: RESOLVED WORKSFORME

(Core :: DOM: Editor, defect)

Description

[Robbie Paplin]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1
Build Identifier: 

If you have a contenteditable div in a document with dir="rtl", the caret will "wrap around" inside of the div, with repeated arrow key events, instead of stopping.

Reproducible: Always

Steps to Reproduce:
1. Goto to attached test case
2. Click on the To field
3. Press the right arrow key repeatedly
Actual Results:  
The right arrow key event keeps moving the caret. After you've reached the end of the contenteditable DIV, the caret "wraps" around back to the beginning of the contenteditable DIV.

Expected Results:  
The right arrow key event should stop moving the caret after you've reached the end of the contenteditable DIV 

Works as expected in IE 7, IE 8 (Beta 2) & Safari

Comment 1

[Robbie Paplin]

Attachment: Caret movement is incorrect in a contenteditable div in a RTL document

Comment 2

[Zack Weinberg (:zwol)]

Attachment: minimized test case

Confirming, and here's a much smaller test case.

To trigger this bug you must have a block-level element which is *directly* contenteditable="true" and *effectively* dir="rtl" (that is, contenteditable must be set on the element itself, but RTL can be by inheritance), and which contains characters which will *not* be rendered right-to-left.  Also, the contenteditable element must have siblings.  Wrapping occurs at the rightmost edge of the div if there is a sibling *before* the element, and at the leftmost edge if there is a sibling *after*.

So, with the attached test case: as is, the effect will show at both edges of the DIV containing the letters "abc".  Changing the editable div to a span, changing the letters within the span to U+05D0, U+05D1, U+05D2 (that is, HEBREW LETTER ALEF, BET, GIMEL) (in any file order), moving the contenteditable attribute to the BODY tag, or adding style="unicode-bidi:bidi-override" to the editable DIV makes the bug disappear entirely.  Removing the DIV containing just a "1" makes the bug not happen at the rightmost edge of the editable DIV.  Removing the DIV containing just a "4" makes the bug not happen at the leftmost edge of the editable DIV.

When all the necessary conditions are met, the true caret position moves from the rightmost to the leftmost edge of the editable block on the first press of the right arrow key, but the visible caret position does not change.  A second press of right arrow then moves both the true and visible caret position to be one character to the right of the leftmost edge.  The same divergence of true and visible caret position occurs for wrapping from leftmost to rightmost.  You can tell that this divergence happens because if the caret is initially on the rightmost edge of the editable block, pressing right arrow once has no visible effect, but then you can press left arrow any number of times and nothing will happen; pressing right arrow again causes the visible caret to jump to between the first and second characters from the left edge of the block.

Comment 3

[Zack Weinberg (:zwol)]

For no apparent reason, a trunk build does not show the caret *at all* with this test case, which makes this basically impossible to debug.  I'm shelving this bug for the time being.

Comment 4

[Chris Pearce [:cpearce (Not reading bugmail)]]

With the minimized testcase I get a caret on Windows trunk, but not on Linux trunk.

Comment 5

[Zack Weinberg (:zwol)]

I've figured out how to make the caret visible again in trunk builds, and I can no longer reproduce the bug with regular keypresses and either the original reporter's test case or my minimized test case.

In a second test case I wrote using privileged Javascript to synthesize key events, the cursor position reported to Javascript is still ... not what one would expect ... but I don't feel comfortable making changes to the heinously complicated cursor-motion code for just that.

I'm resolving this WORKSFORME.  Please reopen if you can still see the bug; please attach a new test case if necessary.

Comment 6

[Zack Weinberg (:zwol)]

Attachment: test case with synthetic keypresses (needs chrome privileges)

Here's the test case I mentioned that uses privileged Javascript to synthesize keypresses.  For it to work you will need to download the file to your local disk, change <script src="file:///home/zack/src/mozilla/moz-central/testing/mochitest/tests/SimpleTest/EventUtils.js"> to refer to your copy of EventUtils.js, and click "Allow" on the various privilege dialogue boxes that come up.

The anomalous behavior I see is: on cursor motion to the right, in both 'test' and 'control', the caret position oscillates between '#text + 3' and '#text + 1' once it reaches position 3.  This may or may not be a bug, but as I said, I'm not comfortable making changes to the caret code just for this relatively contrived test case.