GNOME Bugzilla – Bug 611256
atk_text_get_text is not working correctly with the specified end offset
Last modified: 2015-02-27 16:54:29 UTC
Steps to reproduce: 1. Launch Accerciser and switch to the iPython console. 2. Launch Gedit and type 'hello'. 3. Locate the accessible object in which 'hello' was just typed in Accerciser. With that object selected/highlighted, type the following in the iPython console: acc.queryText().getText(0, -1) Expected results: 'hello' is returned. Actual results: 'hello' is returned. 4. Launch a Java app, e.g. Notepad.jar and type 'hello'. 5. Locate the accessible object in which 'hello' was just typed in Accerciser. With that object selected/highlighted, type the following in the iPython console: acc.queryText().getText(0, -1) Expected results: 'hello' is returned. Actual results: '' is returned. Impact: Orca expects to be able to get all of the text in an object by specifying a start offset of 0 and an end offset of -1. Because this fails for Java apps, any command in which Orca attempts to get all of the text of an object in a Java app will fail.
Found another end offset issue with the implementation of atk_text_get_text, so I'm adjusting the summary. Repeat the above steps for both gedit and a Java app (e.g. Notepad.jar). But this time, instead of using -1 as the end offset, use a proper offset. Gedit: getText(0, 1) returns 'h' Notepad.jar: getText(0, 1) returns '' Gedit: getText(0, 2) returns 'he' Notepad.jar: getText(0, 2) returns 'h' This is why, if Orca is set to echo words, and the user types 'hello' and then presses Space or Period: * In Gedit, Orca says 'hello' * In Notepad.jar, Orca says 'hell'
Fix will be delivered into JAW 0.29.6
[Moving at-spi/java-atk-wrapper bugs to separate product. See bug 740075]