Bug 7433 – REGRESSION (r12789): Second RTL text run on a line cannot be selected

• Status: VERIFIED
• Resolution: FIXED
• Component: Layout and Rendering

Clicking or dragging to select the second run and subsequent runs of RTL text on a line fails. See the test case for an example where you cannot drag or double-click to select the rightmost two words of Hebrew text, since they are separated from the first two words by a double space (causing them to be in a different text run).

Using nightly builds I tracked it down to somewhere between r12786 and r12791, and r12789 looks like the most likely candidate to be the cause.

Created attachment 6687 [details]
Test case

This bug is a result of Position::inRenderedText()'s assumption that RenderText's inline boxes are ordered by their start offset. This assumption is false in many bidi contexts.

The same logic is used in at least two other places: Position::isRenderedCharacter() and RenderText::inlineBox().

Created attachment 6746 [details]
Fix the regression

This fixes inRenderedText() (which is responsible for this bug) and isRenderedCharacter(), but not other places where logical ordering of the text boxes is wrongly assumed. Those seem to be in editing code and require separate bugs and test cases.

[Darin Adler]

Comment on attachment 6746 [details]
Fix the regression

These fixes seem to leave in an optimization for renderers that don't contain reversed text. But couldn't we just remove the optimization entirely?

[David Harrison]

I would think so.  Before my patch, Position::inRenderedContent had this optimization but VisiblePosition::isCandidate() did not.

[Darin Adler]

Comment on attachment 6746 [details]
Fix the regression

Lets get this fix landed -- we can ponder whether to remove the regression altogether later.

r=me

[Darin Adler]

Comment on attachment 6746 [details]
Fix the regression

I meant to say "we can ponder whether to remove the *optimization* altogether later".

Verified in r13060 nightly