On Fri, Apr 12, 2013 at 6:01 PM, Ryosuke Niwa <rn...@webkit.org> wrote: > On Fri, Apr 12, 2013 at 10:00 AM, Ryosuke Niwa <rn...@webkit.org> wrote: >> >> On Fri, Apr 12, 2013 at 9:50 AM, Sergio Villar Senin <svil...@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? _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev