| Summary: | right/left arrow keys move forward/backward through document instead of right/left in RTL text | ||||||
|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Darin Adler <darin> | ||||
| Component: | HTML Editing | Assignee: | mitz | ||||
| Status: | RESOLVED FIXED | ||||||
| Severity: | Major | CC: | ian, KwhiteRight, mitz, mohannad.harthi, oliver | ||||
| Priority: | P1 | Keywords: | InRadar, Regression | ||||
| Version: | 412 | ||||||
| Hardware: | Mac | ||||||
| OS: | OS X 10.4 | ||||||
| Bug Depends on: | 3710 | ||||||
| Bug Blocks: | |||||||
| Attachments: |
|
||||||
My patch in bug 3710 has some relevant related changes, so it might be good to fix that bug first. Raising to P1 since this causes a regression with the new text fields. These are all text field regressions so they should all be P1. Here's one of the relatively simple cases that I just don't know how to solve (uppercase letters are RTL): <div style="direction:ltr"> abcABC<span>DEF</span> </div> It is laid out as abcFEDCBA The primary caret positions, from left to right, should be: div.text[0] div.text[1] div.text[2] div.text[3] span.text[2] span.text[1] span.text[0] div.text[5] div.text[4] span.text[3] That last step, from div.text[4] to span.text[3] is the tricky one, and so is recognizing that span.text[3] is a rightmost position. There is also a variant where there is another text node after the span, but that text node wraps to the next line. Created attachment 10786 [details]
unfinished patch
Here's an unfinished patch written a while back by an Apple Engineer.
Fixed in <http://trac.webkit.org/changeset/32605>. |
Also in Radar as: <rdar://problem/4036353> RTL: arrow keys move insertion bar backwards in RTL text Easy to reproduce by typing in some Hebrew text, and then using the arrow keys. You'll move forward/ back through the document rather than left/right through the visible text.