Summary: with certain fonts, contracting the selection by moving its start rightwards leaves trails of the highlight behind. To reproduce: open the testcase in Safari. Click and drag in one motion from the end of the line to its beginning (extending the selection leftwards) and all the way back to the end (contracting the selection). Expected result: no trails left behind. Actual result: when the left border of the highlight is moving to the right, it leaves behind 1px-wide trails. I think this happens because the clipping rect for the redraw is determined by WebCore using integral coordinates and drawing the highlight is done in WebTextRenderer using non-integral coordinates (or perhaps applying a different rounding rule).
Created attachment 4402 [details] testcase
Created attachment 4448 [details] extended testcase Added RTL case.
Created attachment 4449 [details] proposed patch This patch fixes the trails bug in the CoreGraphics code path for LTR and RTL text (highlighting for RTL text was entirely broken very recently) and in the ATSUI code path for LTR text (highlighting and hit-testing RTL text in the ATSUI path is broken and I'll open a separate bug for it. I already have a patch). This patch eliminates the single-character-range special case in the rounding hack. One layout test is affected: fast/text/international/bidi-explicit-embedding . The new results should replace the current expected results.
Comment on attachment 4449 [details] proposed patch Looks good. r=me
Committed. Test case added as WebCore/manual-tests/drag_select_highlighting.html