Closed Bug 1336388 Opened 7 years ago Closed 7 years ago

[RTL] Text selection handles appear inverted under some circumstances


(Core :: DOM: Selection, defect)

Not set



Tracking Status
firefox54 --- fixed


(Reporter: itiel_yn8, Assigned: TYLin)


(Blocks 1 open bug)


(Keywords: rtl)


(4 files)

Attached file Testcase
1. Install Nightly RTL build
2. Open
3. Long tap one of the English words- the selectors look okay
4. Long tap one of the Hebrew words- the selectors look inverted

Basically if text that has RTL directionality appears as LTR (and vise versa), the selectors would appear as inverted.
I have attached a testcase that has English and Hebrew text that appear on different directionality declarations for you to test.
Hi TY,
Per talked, would you help to take a look on this bug please? Thank you.
Flags: needinfo?(tlin)
This bug only occurs on Fennec because Fennec enables "layout.accessiblecaret.always_tilt". Interesting, Google Chrome (on Android) seems to have the same issue once the user starts dragging caret. on the text that has RTL directionality appears as LTR (and vise versa).

I can reproduce this issue on Firefox Desktop with the following pref.
* "layout.accessiblecaret.enabled" sets to true.
* "layout.accessiblecaret.hide_carets_for_mouse_input" sets to true.
* "layout.accessiblecaret.always_tilt" sets to true.

This bug occurs only on Fennec because Fennec enables "layout.accessiblecaret.always_tilt".
Flags: needinfo?(tlin)
The caret tilt direction is controlled by [1]. Currently, we only look at the directionality of the frame, not the directionality of the text. I admit the tilted carets look awkward if the directionality of the text is in a content container with opposite "dir" attribute such as English words are in the middle of Hebrew text [2]. The tilted carets might be overlapping under such circumstances. 

[2] Hebrew Wikipedia's Firefox page
Attached image carets-overlapped.png
I don't feel the direction of the carets on LTR text in RTL environment dampens the usability. The real issue is the overlapping carets like the screenshot shown prevents the user from adjusting the selection range.

I see two options to fix this bug.

1) Use the language's directionality to tilt the caret. However, this approach doesn't work well. The caret will swing from left to right (or vice versa) when being dragging across the boundary of RTL and LTR text or a space (because the "space" character doesn't have directionality)

2) The direction of the two carets stays the same like it was, but we separate the inward carets when they're too close. We use the same approach like "layout.accessiblecaret.always_tilt" is off. I'll post a patch later.
Attach the patch for approach 1 in comment 4 for the record. It doesn't work well.
Assignee: nobody → tlin
Component: Text Selection → Selection
Product: Firefox for Android → Core
Comment on attachment 8834796 [details]
Bug 1336388 - Use overlapping tilt mechanism in always tilt mode.
Attachment #8834796 - Flags: review?(mtseng) → review+
Pushed by
Use overlapping tilt mechanism in always tilt mode. r=mtseng
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla54
Woot! Thank you Ting-yu for the quick turnaround!
This patch indeed fixes the carets being overlapped but it doesn't cover all scenarios, including what I've mentioned in comment 0.
Can it be addressed in this bug or should I open a new one?
Flags: needinfo?(tlin)
I'm aware that the carets would appear as inverted on text that has RTL directionality in dir=ltr environment (and vise versa). However, using text's directionality to make them look normal doesn't seem good to me (see the reason of approach 1 in comment 4). A third approach could be that we use the absolute x-position of the carets to decide their appearance, but the carets will still swing back and forth when their x-position exchanged.

To keep the caret's appearance being consistent tilted to either left or right in either LTR or RTL environment regardless of the text's directionality, the inverted carets is a natural consequence.
Flags: needinfo?(tlin)
You need to log in before you can comment on or make changes to this bug.