In bug 406069 we implemented a fix allow -2 to be passed in as an offset to text getter methods. However, Joanie reports that it's not working, at least on Linux. Try it in Accerciser: text = acc.queryText() text.getTextAtOffset(-2, TEXT_BOUNDARY_LINE_START) <joanie> when I try to use it I get an empty string a starting offset of 0 and an ending offset of some really large number From what Joanie says it sounds like it's getting changed to an unsigned int somewhere. Somewhere we're using the wrong int type. The bug could be in Mozilla, but I don't see where. Or maybe in pyatspi. Probably -1 for end of text is broken as well!
It could also be in the ATK bridge somewhere. I don't see a problem in the Mozilla code. All text/hypertext interface method implementations should use signed numbers for offsets. Anywhere that an offset is assigned to an unsigned number the value will be seen as a large number.
OK, here's the story: We never receive negative offsets out of ATK. ATK itself returns a NULL string in ATK_TEXT_GET_TEXT_AT_OFFSET in the event it receives a negative index. So, Orca pushes the -2 into PYATSPI, it travels fine through AT-SPI, and from there it travels to ATK. In ATK, it gets stopped. See http://svn.gnome.org/svn/atk/trunk/atk/atktext.c, line 380. I'll file a follow-up bug to Gnome's bugzilla to get a discussion about extending the API to allow -1 and -2 for indexes. -1 being all text, -2 being the current line, meaning if the application receives -2, it should always think of this as the line the cursor is on.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → INVALID
The follow-up ATK bug is here: http://bugzilla.gnome.org/show_bug.cgi?id=508846. For reference, a more detailed explanation of the intended usage of -1 and -2 can be found here: http://developer.mozilla.org/en/docs/Accessibility:Architecture#.28F.29_To_get_the_line_of_text_at_the_caret.
You need to log in before you can comment on or make changes to this bug.