W dniu 2014-05-06 12:46, Mario Sanchez Prada pisze:
Hi Jarek,
I think that idea of using AccessibilityUIElement.setSelectedTextRange() and
calling atk_text_set_caret_offset() when length == 0 might work, so I'm all
for trying that out. After all, internally in WebKit, Caret positions are
treated as zero-length selections anyway, so it's not that inconsistent.
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. 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.
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.
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.
Jarek
[1] https://bugs.webkit.org/show_bug.cgi?id=132527
_______________________________________________
webkit-gtk mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-gtk