[Webkit-unassigned] [Bug 41485] Crash in replaceSelectionCommand with RTL text

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=41485


Julie Parent <jparent at google.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |darin at apple.com,
                   |                            |kocienda at apple.com




--- Comment #6 from Julie Parent <jparent at google.com>  2010-07-02 16:52:39 PST ---
(Added original author and reviewer of the code in question)

Additional details on what is going on here, and why my initial patch is wrong:

The crash only happens inside a dir=rtl area, when the text is english, with a space.  Specifically, given the following 4 cases:
1. RTL region, english text: <div dir='rtl' style='white-space:pre' contentEditable >the </div>
2. LTR region, english text: <div dir='ltr' style='white-space:pre' contentEditable >the </div>
3. RTL region, arabic text: <div dir='rtl' style='white-space:pre' contentEditable >אחת </div>
4. LTR region, arabic text: <div dir='rtl' style='white-space:pre' contentEditable >אחת </div>

Currently, the crash only happens with case #1.  With my patch, #1 doesn't crash, but #4 does.

For these cases, we have the following InlineTextBoxes.

Case 1:
Box: start 3, len 1.  Next box: start 0, len 3 (box for the space with direction = RTL, box for "the" with direction = LTR)
Case 2:
Box: start 0, len 4 (box for the whole thing "the ", direction LTR)
Case 3:
Box: start 0, len 4 (box for the whole thing "אחת ", direction RTL)
Case 4:
Box: start 0, len 3. Next box: start 3, len 1 (box for "אחת" with direction RTL, box for space direction LTR)

So in the case of single directionality, there is a single box spanning the entire thing.  In the cases of mixed directionality, there is a box for the word and a box for the space.

Inside CompositeEditCommand::deleteInsignificantText, it tries to compute "gaps" using these boxes.  In case #1, it computes 0-3 aka, "the" as a gap, although it is text.  I think that is what goes wrong, but I don't really understand the code well enough.

My patch changed it to start with the last box rather than the first in the case of RTL, but that just swapped cases 1 and 4, so clearly isn't correct.

Anyone familiar with that code have any thoughts?  This is 6 years old, from http://trac.webkit.org/changeset/7875, and doesn't seem like it has been touched much.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.