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

Ryosuke Niwa rniwa at webkit.org
Fri Apr 12 10:01:41 PDT 2013

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20130412/65d0f0f8/attachment.html>

More information about the webkit-dev mailing list