On Fri, Apr 12, 2013 at 10:07 AM, Shezan Baig <[email protected]> wrote:
> On Fri, Apr 12, 2013 at 6:01 PM, Ryosuke Niwa <[email protected]> wrote: > > On Fri, Apr 12, 2013 at 10:00 AM, Ryosuke Niwa <[email protected]> wrote: > >> > >> On Fri, Apr 12, 2013 at 9:50 AM, Sergio Villar Senin < > [email protected]> > >> 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
_______________________________________________ webkit-dev mailing list [email protected] https://lists.webkit.org/mailman/listinfo/webkit-dev
