875794 - get text at offset for line boundary fails on last empty line

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[Marco Zehe (:MarcoZ)]

STR:
1. With NVDA running, either connect a braille display.
2. Find any textarea.
3. Type something.
4. press Enter.

Expected: Braille display should be blank, with cursor blinking on first cell of the line.
Actual: Text remains on the display, and the cursor blinks after the last character, as if no newline was inserted.

This is a regression from bug 873358 and first appears in 24.0a1 (2013-05-24).

Comment 1

[alexander :surkov (:asurkov)]

Jamie, could you take a look what's broken? Presumably it is something wrong with text interface line boundary?

Comment 2

[James Teh [:Jamie]]

Consider a textarea where you type "test" and then press enter, so the entire text is "test\n". IAccessibleText::textAtOffset(4, IA2_TEXT_BOUNDARY_LINE) (4 is the line feed) returns offsets of (0, 5), which is correct. However, IAccessibleText::textAtOffset(5, IA2_TEXT_BOUNDARY_LINE) (5 is where the caret lands after pressing enter) returns offset of (0, 4). Aside from being oddly inconsistent (why 4 instead of 5?), this is incorrect, since we're on the new line, so it should be at least (5, 5).

The tricky part is that there's actually no character there yet, which makes bounds checking a bit weird. Essentially, we have to pretend there's a character there.

Comment 3

[alexander :surkov (:asurkov)]

(In reply to James Teh [:Jamie] from comment #2)
> Consider a textarea where you type "test" and then press enter, so the
> entire text is "test\n". IAccessibleText::textAtOffset(4,
> IA2_TEXT_BOUNDARY_LINE) (4 is the line feed) returns offsets of (0, 5),
> which is correct. However, IAccessibleText::textAtOffset(5,
> IA2_TEXT_BOUNDARY_LINE) (5 is where the caret lands after pressing enter)
> returns offset of (0, 4). Aside from being oddly inconsistent (why 4 instead
> of 5?), this is incorrect, since we're on the new line, so it should be at
> least (5, 5).

yep (5,5) seems correct here (I'm pretty sure we have todo in our test suite for this)

> The tricky part is that there's actually no character there yet, which makes
> bounds checking a bit weird. Essentially, we have to pretend there's a
> character there.

so if we return (5, 5, "") then it is still a problem for NVDA?

Comment 4

[James Teh [:Jamie]]

(In reply to alexander :surkov from comment #3)
> > The tricky part is that there's actually no character there yet, which makes
> > bounds checking a bit weird. Essentially, we have to pretend there's a
> > character there.
> so if we return (5, 5, "") then it is still a problem for NVDA?
Not at all. I was just making an observation about why the regression probably crept in.

Comment 5

[alexander :surkov (:asurkov)]

ok, thanks. renaming bug

Comment 6

[alexander :surkov (:asurkov)]

Attachment: part1: line start case

Comment 7

[alexander :surkov (:asurkov)]

Attachment: part2: line end case

Comment 8

[alexander :surkov (:asurkov)]

Comment on attachment 756398 [details] [diff] [review]
part1: line start case

canceling review, replaced by bug 882281

Comment 9

[alexander :surkov (:asurkov)]

http://hg.mozilla.org/integration/mozilla-inbound/rev/f2e3ec8e72ab

Comment 10

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/f2e3ec8e72ab

Comment 11

[alexander :surkov (:asurkov)]

part2: http://hg.mozilla.org/integration/mozilla-inbound/rev/29139ed969a5 (pulls r+ from bug 882281)

Comment 12

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/29139ed969a5