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

Reply via email to