1067796 - Caret gets stuck in mixed direction text

Status: RESOLVED FIXED

(Core :: DOM: Editor, defect)

Description

[Simon Montagu :smontagu]

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)

Comment 1

[Simon Montagu :smontagu]

Regression range http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=053a96e40244&tochange=94ba78a42305

Bug 1048752, but it would be good to pin it down to an individual checkin

Comment 2

[Simon Montagu :smontagu]

Raising severity: this makes text entry almost unusable for right-to-left or mixed direction text

Comment 3

[(no longer active)]

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)

Comment 4

[Simon Montagu :smontagu]

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?

Comment 5

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I'm guessing the bidi-keyboard related stuff, but I don't really know.

Comment 7

[Simon Montagu :smontagu]

So this is caused by http://hg.mozilla.org/mozilla-central/rev/ea929ba6a8fc

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.

Comment 8

[Simon Montagu :smontagu]

Attachment: Patch

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 http://hg.mozilla.org/mozilla-central/rev/f016da18b899 which was made as a consequence of calling SelectionLanguageChange when the language hadn't changed.

Comment 9

[Simon Montagu :smontagu]

https://hg.mozilla.org/integration/mozilla-inbound/rev/f78b883da6fd

Comment 10

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/f78b883da6fd