Caret gets stuck in mixed direction text

RESOLVED FIXED in mozilla37

Status

()

Core
Editor
--
major
RESOLVED FIXED
4 years ago
3 years ago

People

(Reporter: smontagu, Assigned: smontagu)

Tracking

({regression, rtl})

Trunk
mozilla37
regression, rtl
Points:
---
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

4 years ago
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)
(Assignee)

Comment 1

4 years ago
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
Blocks: 1048752
Keywords: regression, regressionwindow-wanted
(Assignee)

Comment 2

4 years ago
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)
(Assignee)

Comment 4

4 years ago
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)
(Assignee)

Updated

4 years ago
Duplicate of this bug: 1110076
(Assignee)

Comment 7

4 years ago
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.
(Assignee)

Comment 8

4 years ago
Created attachment 8546006 [details] [diff] [review]
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.
Attachment #8546006 - Flags: review?(roc)
https://hg.mozilla.org/mozilla-central/rev/f78b883da6fd
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla37

Updated

4 years ago
Keywords: dev-doc-needed

Updated

3 years ago
Keywords: dev-doc-needed
You need to log in before you can comment on or make changes to this bug.