[webkit-gtk] testing text-caret-moved events
Mario Sanchez Prada
mario.prada at samsung.com
Tue May 6 06:46:27 PDT 2014
> 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
PlainTextRange textRange(offset, 0);
VisiblePositionRange range =
> 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
> 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
> Please say which way to go and I'll prepare a patch. I'll join it with
> the previous patch (text-caret-moved) , 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 :)
More information about the webkit-gtk