[webkit-dev] Overtype mode in WebKit for editable content?

[Shezan Baig]

On Fri, Apr 12, 2013 at 6:01 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:
> On Fri, Apr 12, 2013 at 10:00 AM, Ryosuke Niwa <rniwa at webkit.org> wrote:
>>
>> On Fri, Apr 12, 2013 at 9:50 AM, Sergio Villar Senin <svillar at igalia.com>
>> wrote:
>>>
>>> I know that WK follows the NSTextView implementation but FF for example
>>> does not show the remote insert issue.
>>
>>
>> Yes, it does.  Firefox simply uses heuristics to guess which type of
>> character LTR/RTL you're about to type.  They still have the same issue.
>>
>>> > The problem here is that caret will be on top of a wrong character.
>>> >  That's much worse than a character being inserted at a remote
>>> > location.
>>> >  Using my existing example, what user sees is:
>>> > 123CBA or 123CBA
>>> > yet what will be replaced is 1.  That's insane.
>>> >
>>> > This is orders of magnitude worse than caret showing up as a vertical
>>> > line at this location:
>>> > 123|CBA
>>>
>>> Yeah I understood you example, it was very descriptive. What I wanted to
>>> share with you is that, in your same example, in "Insert" mode, placing
>>> the caret at (3) will insert the next character before the 1. Isn't that
>>> insane too?
>>
>>
>> No.  The caret simply shows the logical insertion point.
>>
>>> > And this is why just setting the width of caret will never work.
>>>
>>> Well, I have a pretty compact patch more or less ready to be uploaded to
>>> bz that in the case of the caret being placed at (3) just draws the
>>> classical 1px width bar (it also draws the thin bar in the case of being
>>> after the last character), so although the replaced character is in any
>>> case the 1, the insanity you mention is somehow minimized.
>>
>>
>> That doesn't sound right either.  It's much more confusing than not
>> setting any width at all because it's the overtype mode is still on.
>>
>> What we need to do is here to use selection.  We need to have 1-character
>> long text selection at all time except at the end of each line when overtype
>> is on since selection code already deals with the said bidi craziness.
>> Anything short of that isn't landable quality.
>
>
> Of course, we need to pretend as if the selection is collapsed still in
> JavaScript APIs.
>
> - R. Niwa
>


Wouldn't it be sufficient to just modify CaretBase::updateCaretRect to
return a rect that covers the next character?  Or am I missing
something?