Closed Bug 1067796 Opened 9 years ago Closed 8 years ago

Caret gets stuck in mixed direction text


(Core :: DOM: Editor, defect)

Not set





(Reporter: smontagu, Assigned: smontagu)



(Keywords: regression, rtl)


(1 file)

Steps to reproduce:

1) Type alternating left-to-right and right-to-left text in a text area, or copy and paste the following line:

abc אבג def ابج

2) Position the caret at one end of the line and use the arrow keys to get to the other end of the line

Expected results: the caret should move from one end of the line to the other, passing over each characters

Actual results: the caret gets stuck on the right-to-left characters (in a left-to-right text area) or the left-to-right characters (in a right-to-left text area)
Regression range

Bug 1048752, but it would be good to pin it down to an individual checkin
Raising severity: this makes text entry almost unusable for right-to-left or mixed direction text
Severity: normal → major
Hmm, I can't reproduce comment 0.  But, when I place the caret after the f, and keep pressing right, we seem to go over ابج in a loop (i.e., we jump back to before the "aleph" aka the left side of "ج" after I press right at the end of the line)
According to user reports this is reproducable on Windows also. roc, do you have an idea what part of bug 1048752 may have caused this?
Flags: needinfo?(roc)
OS: Mac OS X → All
Hardware: x86 → All
I'm guessing the bidi-keyboard related stuff, but I don't really know.
Flags: needinfo?(roc)
So this is caused by

I'm not sure how to fix it without reinstating at least some of the bogusness referred to in bug 1048752 comment 25, but SelectionLanguageChange should only be called when the language actually changes. Its sole purpose is to handle the situation when the caret is between two directional runs and the directionality of the keyboard language changes, so the caret needs to move to the expected visual position of the next character typed. If it's called when the language hasn't changed but the position of the caret has changed, the caret jumps to the wrong location.
Attached patch PatchSplinter Review
Hopefully caching the keyboard language direction on the Selection is less bogus than on the caret.

I've also reverted the change to the test for bug 646382 from which was made as a consequence of calling SelectionLanguageChange when the language hadn't changed.
Attachment #8546006 - Flags: review?(roc)
Closed: 8 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla37
Keywords: dev-doc-needed
Keywords: dev-doc-needed
You need to log in before you can comment on or make changes to this bug.