[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