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

[Sergio Villar Senin]

En 12/04/13 18:17, Ryosuke Niwa escribiu:
> On Fri, Apr 12, 2013 at 4:40 AM, Sergio Villar Senin <svillar at igalia.com

>     For example consider the strongly LTR letters
>     "abc" inside a RTL block, which will be rendered as "abc". If we either
>     place the caret at the beginning (before 'a') or at the end (after 'c')
>     the next typed character will be placed at the opposite side the user
>     might expect based on the caret position.
> 
> 
> That's expected.

I know it's expected :) but that does not mean that characters appearing
at remote locations (from caret POV) is not weird. I know that WK
follows the NSTextView implementation but FF for example does not show
the remote insert 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?

> 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.

BR