473206 - GetTextAtOffset returns wrong values for the current line if the source file contains carriage returns.

Status: RESOLVED WORKSFORME

(Core :: Disability Access APIs, defect)

Description

[Marco Zehe (:MarcoZ)]

STR:
1. Unzip and open the attached testcase.
2. Focus on the textbox.
3. Press Ctrl+Home to get to the beginning.
4. Press DownArrow.
5. Use the GetTextAtOffset method to retrieve the current line, using BOUNDARY_LINE as the boundary type, and -2 as the offset, indicating that you want to get the current line the caret is sitting on.

Expected: You'd get "This is another line of text." and the according offsets returned.
Actual: You get "This is the first line...", and values of 0 and 34 as starting and ending offsets.

6. Edit the editable.htm file and remove the line break after the first html:br tag.
7. In Firefox, refresh the page.
8. Repeat steps 2 through 5.

Actual result: This time, you get the correct second line of text and the corresponding offsets returned.

In other words: The physical line break in the source file causes some astray accessibles throwing things off-step.

Comment 1

[Marco Zehe (:MarcoZ)]

Alex, do you have any ideas on this one? Could you take a look to see if you can find the cause? You could do this while I review your relations patch. ;-)

Comment 2

[alexander :surkov (:asurkov)]

Marco, the problem is bigger than this bug (blocked bug 368895). I want to get mochitests (bug 452769) for these things before I'll start to change the code (because this code is very complicated and I really afraid to broke something else). This mochitests bug is blocked by ATK bug (http://bugzilla.gnome.org/show_bug.cgi?id=551489) because Gecko Text API corresponds to ATK. This is the reason why I leaved this issue.

Comment 3

[alexander :surkov (:asurkov)]

(In reply to comment #2)
> This mochitests bug is blocked by ATK bug
> (http://bugzilla.gnome.org/show_bug.cgi?id=551489)

It seems there is consensus there. I'll try to get back to this soon.

Comment 4

[Marco Zehe (:MarcoZ)]

Not a regression, but this hits JAWS 10 (and possibly other screen reader) users everytime they arrow around a textarea or RichText form field and hit the end of a line. Screen readers falsely report the first character of the next line because of this bug.

Comment 5

[alexander :surkov (:asurkov)]

It doesn't look the test case is attached to the bug.

Comment 6

[Marco Zehe (:MarcoZ)]

Just type a few words in this comment field until the line wraps. Then, with NVDA running, arrow right over the last word of the first line and to the first word of the second line. You'll hear it. I also did testing with AccProbe back then when I discovered the bug.

Comment 7

[Marco Zehe (:MarcoZ)]

Alex, can we attempt to finally fix this, please? Pretty please? ;)

Comment 8

[alexander :surkov (:asurkov)]

(In reply to Marco Zehe (:MarcoZ) from comment #7)
> Alex, can we attempt to finally fix this, please? Pretty please? ;)

I'm sorry, I could put it into my queue, but I afraid I won't be able to get close in reasonable time. The text bugs are huge area and it's easy to get swamped there. I'd say the area needs its own owner/driver.

For now I'd be helpful to triage the bug to determine, whether this is a layout bug or a11y's one, or create an automated test to demo the problem.

Comment 9

[Marco Zehe (:MarcoZ)]

I am thinking this bug is fixed by now. I believe we've had fixes in the past that made this bug go away. And I do not reproduce this any more with NVDA and current Firefox nightly build.