GNOME Bugzilla – Bug 171581
wrong line start report for an object with 'text' role
Last modified: 2005-04-04 14:09:12 UTC
Run Swing Demo. Choose 'TextArea Two'. The line start for the text object is -1.
AccessibleText_getTextAtOffset (text, offset, acc_type_text, &start, &end) returns a negative value for 'start' parameter.
AccessibleText_getTextAtOffset (text, offset, SPI_TEXT_BOUNDARY_LINE_START, &start, &end) returns a negative value for 'start' parameter if offset is placed in the first line of a multiline text and it returns a wrong value, also,(the good value for the start line - (minus) 1) if the offset is placed in other line.
The same behavior is present for SPI_TEXT_BOUNDARY_SENTENCE_START type (and SPI_TEXT_BOUNDARY_SENTENCE_END). Wrong values will be returned for start and end of sentence.
*** Bug 171583 has been marked as a duplicate of this bug. ***
Created attachment 39381 [details] [review] patch to fix problem Oana, please report whether the attached patch to java-access-bridge solves your problem. It seems to solve the immediately visible brlmonitor issue, but I haven't confirmed that it works correctly for sentences, etc.
The patch solves only the case for the first line. If the offset is in any other line, except the first one, the start of the line is wrong. Also, wrong values are obtained for start and end of sentence.
the rest of the bug seems to be in Java, then.
Try the latest cvs version of java-access-bridge; it also reports text-change strings in the CORBA_Anys sent from the currently-focussed object.
With the latest version of java-access-bridge, I saw the following in Swing Demo: - writing a text ('abcdef') in a text box, then deleting it (using 'backspace' or 'delete') char by char, the deleted text is sometimes null and sometimes has a wrong value. - sometimes, when deleting a char from the text box, the 'text-changed:delete' event is not reported (for example if I want to delete the 'f' from the 'abcdef' string, only the 'caret-moved' event is reported). This behavior is present for multipleline and also for singleline text boxes.
Oana, are you using the version that was distributed via email this afternoon? It should have solved the issues in comment #9 (I don't see them). Also please indicate which 'text box' you are using in which 'Swing Demo' - are you using SwingSet2? If so, which widgets are you testing?
All the tests were made with the cvs version. I didn't received at that time the new version. I used Swing Demo. The text boxes from 'TextArea Two', 'Text Fields', 'More labels' and 'Label' tags were used for tests.
I will make all the tests again with the new version.
I made again all the tests with the new version. The deleted text and the events are reported correctly. The behavior shown in comment #9 is not present anymore.
Thanks. However we seem to have gotten off-topic for this bug, which was about offsets for LINE and SENTENCE. Should we open a separate bug and put the comments (above) there?
Yes, that would be great.
I copied comments #8 through #15 into bug 171584, which I believe is the correct bug for this issue (text-change event strings). So, this bug report can be only about line and sentence start/end offsets.
I have confirmed that sentence start/end offsets are sometimes reported incorrectly; this may be a java-bridge bug.
The root cause appears to be an inconsistency in the strings reported by AccessibleText.getAtOffest versus AccessibleText.getAfterOffset; getAfterOffset seems to include a trailng carriage return if you're on the last line of text, but getAtOffset never does. This is a Java bug. It may be possible to work around it by detecting and stripping the trailing carriage-return.
I believe this is now fixed in CVS; tests which I've carried out now report correct start and end offsets for all but the last character in multi-line text (that last corner case is a Java problem which may not be practical to work around). Please reopen if significantly wrong text offsets are observed.
With the new version of java-access-bridge from cvs, the line start is not correct. I've tested with Swing Demo, for 'TextArea Two' tab. For the description text box ("This example shows the use..."), the start offset for the first line is correct, but for the other lines, the start offset is not correct.
Oana: can you please provide some examples, with the expected correct values? Are you talking about an 'off by one' error?
For the example from comment #21, if the carret position is on the first line in the text box, this text will be reported on braille monitor: "This example shows the use of...". The carret position on braille monitor is good and, also, the reported text is correct. If I move down, to the second line of this text box, the reported text will be: "_editable. The accessible...", where "_" is <space>. The carret position on braille monitor is not correct. In this case, the start offset for this line is wrong. (the start offset is the good value - (minus) 1).
This behavior is present, also, if I write a 'multi-line' text in the empty text box from 'TextArea Two'. (don't use <enter> to add a new text line).
I fixed an off-by-one problem in the getLine method in the java bridge.