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

[Ryosuke Niwa]

On Fri, Apr 12, 2013 at 10:07 AM, Shezan Baig <shezbaig.wk at gmail.com> wrote:

> 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.
>
> Wouldn't it be sufficient to just modify CaretBase::updateCaretRect to
> return a rect that covers the next character?  Or am I missing
> something?
>

No.  That was the whole point of my example and argument.

- R. Niwa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20130412/dfd14bee/attachment.html>