Bug 16001 – REGRESSION: RTL selection is painted incorrectly

• Component: Layout and Rendering
• Status: RESOLVED FIXED

[Alexey Proskuryakov]

Steps to reproduce:
1. Open the bug URL.
2. Focus the editable div.
3. Select 9 characters from the left (with shift-right arrow).

Expected results: "abc", "1" and "אבג" are selected.
Actual results: "דהו" appears selected, too, although with a different look. However, cut/delete work correctly.

Tested with release Safari/WebKit on 10.4.10 and 10.4.11.

The same thing happens with non-editable text. Any idea when the regression happened?

[David Kilzer (:ddkilzer)]

This bug appears to reproduce with the earliest known nightly, r11976, with Safari 2.0.4 on Mac OS X 10.4.11 (8S165).

<rdar://problem/5788857>

[Xiaomei Ji]

Also reported in Chrome:
http://code.google.com/p/chromium/issues/detail?id=3830

besides shift+arrow, shift+cntl+arrow does not work correctly either.

I am trying to add InChromeBugs in keywords, but I do not have the right permission.

(In reply to comment #4)
> Also reported in Chrome:
> http://code.google.com/p/chromium/issues/detail?id=3830

That bug is not related to this one. It is related to bug 3729 and covers cases not addressed by the patch for that bug.

[Jeremy Moskovich]

Created attachment 26250 [details]
LayoutTests/editing/selection/extend-selection-bidi.html

Layout Test

[Jeremy Moskovich]

Created attachment 26251 [details]
LayoutTests/editing/selection/extend-selection-bidi.html

Fix formatting.

[Jeremy Moskovich]

Created attachment 26268 [details]
Patch w/Layout Test

Make RootInlineBox::fillLineSelectionGap() not assume a contiguous visual LTR selection range.

[Xiaomei Ji]

Still think the following 2 Chrome bugs are related:

http://code.google.com/p/chromium/issues/detail?id=3830 (wrong highlight on pure RTL text selection)
and
http://code.google.com/p/chromium/issues/detail?id=4556 (wrong highlight on mixed RTL/LTR text selection)

[Darin Adler]

Comment on attachment 26268 [details]
Patch w/Layout Test

Does this regression test really work in an automated way, or is it only possible to judge its success or failure based on pixel results? Just curious.

r=me

[Jeremy Moskovich]

Thanks for looking at this Darin!

Since this is essentially a drawing bug and the surrounding data structures contain valid data, I'm not sure how to create a test for this which isn't pixel based.

[Alexey Proskuryakov]

Committed revision 39785.

Note that this patch didn't include pixel results, so I had to re-generate them (svn-create-patch script would have handled binary files correctly). Also, its a bit strange that results are not in platform directory, unlike other editing/selection results.