After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
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.
Extend allowed indexes of ATK_TEXT_GET_TEXT_AT_OFFSET and ATK_TEXT_GET_CHARAC...
Status: RESOLVED OBSOLETE
Product: atk
Classification: Platform
Component: atk
unspecified
Other All
: Urgent enhancement
: ---
Assigned To: ATK maintainer(s)
ATK maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2008-01-11 20:53 UTC by Marco Zehe
Modified: 2016-04-10 16:26 UTC
See Also:
GNOME target: ---
GNOME version: Unversioned Enhancement


Attachments
atk patch (1.01 KB, patch)
2008-01-31 10:25 UTC, Li Yuan
committed Details | Review

Description Marco Zehe 2008-01-11 20:53:41 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.
Comment 2 Marco Zehe 2008-01-15 10:14:39 UTC
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.
Comment 3 Li Yuan 2008-01-24 08:56:02 UTC
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?
Comment 4 Willie Walker 2008-01-24 13:21:54 UTC
(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.
Comment 5 Li Yuan 2008-01-25 15:15:58 UTC
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.
Comment 6 Willie Walker 2008-01-29 18:15:40 UTC
(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?
Comment 7 Li Yuan 2008-01-30 05:57:07 UTC
> 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.
Comment 8 Oliver Braun 2008-01-31 05:43:08 UTC
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).
Comment 9 Li Yuan 2008-01-31 10:25:14 UTC
Created attachment 104101 [details] [review]
atk patch

OK, this is the patch for atk. I will make another patch for gail later.
Comment 10 Li Yuan 2008-11-07 07:03:14 UTC
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?
Comment 11 Matthias Clasen 2016-04-10 13:57:23 UTC
moving this bug to atk, since it has an atk patch
Comment 12 Alejandro Piñeiro Iglesias (IRC: infapi00) 2016-04-10 16:26:36 UTC
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.