[webkit-gtk] testing text-caret-moved events

[Mario Sanchez Prada]

Hi Jarek,

> [...] 
> Mario, later I thought more about it. length == 0 may have a specific
> meaning and may possibly be used to clear the selection. I have no idea
> whether atk_text_set_caret_offset clears the selection too.

Ah! I think you are right here in what that length == 0 might be used from
WKTR to test clearing the selection, but I still think it might be worth
trying since, even if the selection is cleared, the cursor would be placed
in the right spot, I believe.

That would be consistent with what atk_text_set_caret_offset() does anyway:

static gboolean webkitAccessibleTextSetCaretOffset(AtkText* text, gint
offset)
{
    [...]

    PlainTextRange textRange(offset, 0);
    VisiblePositionRange range =
coreObject->visiblePositionRangeForRange(textRange);
    if (range.isNull())
        return FALSE;

    coreObject->setSelectedVisiblePositionRange(range);
    return TRUE;
}

> However I
> can't imagine a situation when someone could be passing a negative
> value for length. So, maybe we better use -1 as the workaround. I'm
> pretty sure it would work well.

FWIW, I would not use -1 for this, as that would be much more confusing
IMHO.
 
> Things would be more clear and readable if we added new api. It's no
> problem for me, I already tried this approach. I can't compile other
> ports, but it should be feasible to provide correct code and let bots
> test it. If other ports have nothing against it, I'm ready to patch.

I would not have any problem with adding new API, but I'd rather explore the
other option first, because I feel it might be good enough for what we need
here.
 
> Please say which way to go and I'll prepare a patch. I'll join it with
> the previous patch (text-caret-moved) [1], which you wanted to be
> accompanied by a testcase. These 2 things together allow to port some
> test from testatk.c.

See my comment above :)

Thanks!
Mario