Accessible text get_offset_at_point is broken for entries in Gtk3
Steps to reproduce:
- Launch gtk3-demo's entry buffer demo
- Type "foo bar baz" in the entry.
- Launch Accerciser.
- In Accerciser, select the label "Entries share a buffer. Typing in one is reflected in the other."
- Type the following in Accerciser's iPython console:
-
acc.queryText().getCharacterExtents(0, WINDOW_COORDS)
. Example results:(5, 5, 9, 23)
. - Use the results from the previous step:
acc.queryText().getOffsetAtPoint(5, 5, WINDOW_COORDS)
. You should get an offset of0
. -
acc.queryText().getCharacterExtents(1, WINDOW_COORDS)
. Example results:(14, 5, 10, 23)
. - Use the results from the previous step:
acc.queryText().getOffsetAtPoint(14, 5, WINDOW_COORDS)
. You should get an offset of1
. - Rinse and repeat. You should continue to find that calling
getOffsetAtPoint
with the coordinates which resulted fromgetCharacterExtents
works as expected.
-
- In Accerciser, select the accessible for the entry where you typed "foo bar baz". Try to perform step 5 on this object. Here's what I get:
-
acc.queryText().getCharacterExtents(0, WINDOW_COORDS)
. Example results:(14, 38, 6, 23)
. -
acc.queryText().getOffsetAtPoint(14, 38, WINDOW_COORDS)
. Example results:-1
(i.e. an error) - BUT using the extents of the bounding box (i.e. from the component interface, e.g.
5, 33
), one can get offset 0 viaacc.queryText().getOffsetAtPoint(5, 33, WINDOW_COORDS)
. - Try to work around this bug:
acc.queryText().getCharacterExtents(1, WINDOW_COORDS)
gives me(20, 38, 10, 23)
.acc.queryText().getOffsetAtPoint(20, 38, WINDOW_COORDS)
fails as before. But the character reports a width of 10. So maybe adding that to the previous character's component extents would work? Nope.acc.queryText().getOffsetAtPoint(15, 33, WINDOW_COORDS)
also returns-1
.
-
I could have sworn the hack around used to work.... Regardless, I've only seen this issue with Gtk entries. It would be nice to have it fixed in Gtk so we can have fewer hacks in Orca.
As for the use case: Orca's Mouse Review feature presents the text under the mouse point (including when the mouse pointer moves within the same text object). As part of that, it asks for the text offset at point. In the case of Gtk3 entries, it fails.
CC: @tyrylu