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.
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?
I would think so. Before my patch, Position::inRenderedContent had this optimization but VisiblePosition::isCandidate() did not.
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
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