464559 - getTextAtOffset sometimes returns more than a character for TEXT_BOUNDARY_CHAR

Status: RESOLVED WORKSFORME

(Core :: Disability Access APIs, defect)

Description

[Joanmarie Diggs]

Taken from http://bugzilla.gnome.org/show_bug.cgi?id=495303

~~~~~~~~~~~~~~~~~~~~
Please describe the problem:
Orca flat review doesn't work correctly on dynamically added texts in XUL
applications.  Instead of reviewing single characters it reviews whole pieces
of texts from the current character to the end of the given text.

Steps to reproduce:
1. Fetch the file http://www.freebsoft.org/~pdm/test8a.xul
2. Display it in the chrome mode in Firefox 3, by using the command line option
`-chrome test8a.xul'.
3. Press the "Add text" button.
4. Use Orca flat review to review characters in various pieces of the text
(e.g. by using the KP-1/2/3 keys), especially in "some text" and in "generated
text".

Actual results:
Flat review works as expected in "some text".  But in "generated text" rest of
the text from the current character position is reviewed instead of just a
single character.

Expected results:
Character flat review should work the same way in both "some text" and
"generated text", i.e. reviewing just single characters.

Does this happen every time?
Yes.
~~~~~~~~~~~~~~~~~~~~

Using Accerciser's iPython Console, I tried to get just the 4th character of 'generated text':

In [1]: text = acc.queryText()
In [2]: text.getTextAtOffset(3, TEXT_BOUNDARY_CHAR)
Out[2]: ('erated text', 3, 14)

Doing the same thing for 'some text' works as expected:

In [3]: text = acc.queryText()
In [4]: text.getTextAtOffset(3, TEXT_BOUNDARY_CHAR)
Out[4]: ('e', 3, 4)

Comment 1

[Marco Zehe (:MarcoZ)]

Attachment: Testcase

STR:
1. Unzip both files to a temp directory.
2. Launch the editable.html file.
3. Move the caret to the graphic before the comma.
4. Execute the getTextAtOffset function.

Expected: Only the embed char with the "ARROWHEAD" text (alt text for the graphic) should be returned.
Actual: The alt text plus the trailing comma is returned.

Comment 2

[alexander :surkov (:asurkov)]

This should be fixed now, Marco, can you check it please?

Comment 3

[Marco Zehe (:MarcoZ)]

This is still reproducible. If I query the text at offset 124 with a parameter of offset type of 0, which is character, i get back the embedded char 0x00ff and the training comma, start offset is 124, end offset is 125.

Comment 4

[alexander :surkov (:asurkov)]

Give me steps to reproduce please.

I tried to reproduce in DOMi. Invoking on section accessible:
output(accessible.getTextAtOffset(124, 0, {}, {}));
return embedded character, length of returned string is 1.

Comment 5

[Marco Zehe (:MarcoZ)]

Argh, you're right, it's a display problem of AccProbe. That's what I used. And the comma is actually the separator between the arguments returned by getTextAtOffset. Start offset is 124, end offset is 125. That seems to indicate this 125th character is NOT included, and the comma is indeed the separator. Sorry about that! You can close this WFM I think.

Comment 6

[alexander :surkov (:asurkov)]

ok, great, thank you!