GNOME Bugzilla – Bug 508846
Extend allowed indexes of ATK_TEXT_GET_TEXT_AT_OFFSET and ATK_TEXT_GET_CHARACTER_AT_OFFSET to allow values -1 and -2.
Last modified: 2016-04-10 16:26:36 UTC
Currently, whenever ATK receives a request to get the text at a given offset, if the offset is less than 0, the functions return NULL or a NULL Character respectively. see http://svn.gnome.org/svn/atk/trunk/atk/atktext.c, lines 209 and 380. However, in Mozilla products, we'd like to give Orca the opportunity to always get the text at the line our browsing cursor is. For that, we allow a value of -2 to be passed into our version of GetTextAtOffset. When we receive that, we look what line we're on and give Orca (or whoever makes the query) the text on the current line with the desired boundary type. However, because of the swallowing of negative indices, -1, which we use for "end of string" (for not knowing the exact length, and saving a call), and -2, which we use for the current line, never get through to us.
See also http://developer.mozilla.org/en/docs/Accessibility:Architecture#.28F.29_To_get_the_line_of_text_at_the_caret:
Clarification, "the line we're on" means the line the caret is. As discussed in the page linked to in the previous comment, there is a difference in caret positions at the end of a line, but the offset is the same as the start of the following line. So, to ensure that the correct text is returned, -2 should be allowed to return the text on the line the caret is actually on, even though the offsets are the same.
OK, I understand the problem. Tried on gedit and OO.o, seems gedit doesn't have such a problem but OO.o does. Will, do you know the situation for OO.o, do they have a plan to support minus offset?
(In reply to comment #3) > OK, I understand the problem. Tried on gedit and OO.o, seems gedit doesn't have > such a problem but OO.o does. Will, do you know the situation for OO.o, do they > have a plan to support minus offset? Hi Li: thanks for looking into this. :-) This represents a subtle API change in that we're adding new semantics to a function parameter. I don't remember us putting a feature enhancement request into the OOo folks, but we should. It will be likely, however, that it will take them a long time to implement it. So, something might need to be done in ATK to account for an implementation that doesn't support the new meaning of the parameter.
It is hard for ATK to tell which the implementation is. I think as a temporary solution, we can just return NULL in gail and OO.o if unsupportted parameter comes in.
(In reply to comment #5) > It is hard for ATK to tell which the implementation is. I think as a temporary > solution, we can just return NULL in gail and OO.o if unsupportted parameter > comes in. > Thanks Li! Will this require a change in gail and OOo? Alternatively, do you know if OOo has defensive code in place to handle offsets outside the range it can handle?
> Thanks Li! Will this require a change in gail and OOo? Alternatively, do you > know if OOo has defensive code in place to handle offsets outside the range it > can handle? > You are welcome! There should be a change in gail's code, but I am not sure the situation in OOo. We can ask Malte, but he hasn't registered in bugzilla.gnome.org, I will forward this bug to him.
OOo already supports the magic index -1 in get_text() in the UNO <-> ATK bridge, so extending this to get_text_[at|after|before]_index should be pretty straight forward (the current implementation returns NULL for negative indexes). Please file an RFE in the OOo IssueTracker and assign it directly to me (obr).
Created attachment 104101 [details] [review] atk patch OK, this is the patch for atk. I will make another patch for gail later.
I am sorry that I forgot the gail patch for a long time. I will do it after the bug triage. Have we fixed the problem in firefox?
moving this bug to atk, since it has an atk patch
Using -1 and -2 as "magic index" seems somewhat hacky to me. Additionally, some time ago we updated the AtkText API, with the input of Orca developers. For example, atk_text_get_text_at_offset is marked as deprecated. Taking all that into account, I will close the bug as OBSOLETE.