Here's a summary of the issues.
1. Bidi adjustment, which is the root cause of all issues (issue 543480)
Blink performs a 1:1 mapping between logical positions and visual positions, even at bidi boundaries. The mapping rule is also very confusing when at line boundary.
Example. <input dir=rtl value=abc>, caret offset 3 is rendered at the left of "a"
2. Confusing typing behavior (issues 8172, 443161, 771129)
With mismatching visual and logical caret positions, it's possible that during typing, new characters don't appear under the caret.
3. Range selection that starts/ends at bidi boundary (issues 90580, 306870, 448758)
With one-to-one mapping between logical and visual positions, if a mouse dragging starts/ends at bidi boundary, it's basically impossible to tell which is the correct logical start/end of the selection. This leads to confusing selection behaviors, where the reverse content got selected.
4. Selection handle positioning (issue 359057)
For a range selection that starts/ends at bidi boundary, its logical start/end do not match its visual start/end. Blink uses the logical start/end + bidi adjustment (which also contains bugs) to place the selection handles, and fails to match the visual start/end.
5. Visual caret movement, or Left/Right arrow keys (issue 162244)
Blink's bidi adjustment has bug in its implementation, and isn't a perfect one-to-one mapping between logical and visual positions. This results in failures in visual caret movements.
6. Mouse clicking at a bidi boundary doesn't set caret under mouse (issue 895005)
This is due to bugs in bidi adjustment, so that bidi adjustment fails to build one-to-one mapping between visual and logical positions.
Comment 1 by xiaoche...@chromium.org
, Oct 12