374100 - getTextAtOffset returns bad offsets for paragraph

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[parente]

Attachment: test page

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a3pre) Gecko/20070315 Minefield/3.0a3pre

Related to, but not the same as, bug #373077.

1) See attached page.
2) Look at the accessible text in sponsored links. It should be the following:

<embed>
The Leading Windows Screen Reader
Low Price Guarantee At EnableMart
www.enablemart.com/WindowEyes

<embed>
Read Anything on-screen with large
clear fonts and colours. Get now!
www.ReadPal.com

3) Use getTextAtOffset(102, TEXT_BOUNDARY_LINE_START). Offset 102 is one past the second embed character.
4) The method returns start=0, end=2, text="". Way off.

Comment 1

[Aaron Leventhal]

It's actually a table cell, with lots of stuff inside of it. What's the actual bug?

Comment 2

[Aaron Leventhal]

No this is our old friend the <br> fix, I wonder what happened.

Second to last test "paragraph with br forcing breaks:" from
http://www.mozilla.org/access/qa/jstest.html

Comment 3

[parente]

Didn't see the br in there, but knew it had to be related somehow. The bug is that the start/end indices are wrong. When I ask for the start of the line at offset 102, I expect to get 102 to 150 or so back. Not start=0, end=2.

This causes LSR to cycle back to the start of the table cell in its walk down the page. Hard to detect cycles of these kinds because they're N steps apart, not just 1 like previous br problems.

Comment 4

[Aaron Leventhal]

Attachment: Use different variable for offset results

Comment 5

[Aaron Leventhal]

The problem is essentially in places like this:

<p>some text<h1>A couple of lines of text</h1> more text</p>
Represented by (where * is the embedded object char 0xfffc)
sometext* moretext

Since we're traversing by lines on the outer hypertext, it's a bit of a problem since several lines are within the embedded object character.

Anyway, I have a patch to make sure it does a better job. It won't choke in this situation anymore, and if you ask to go to the next line while on an embedded object char that represents multiple lines, you'll end up at the next char. Alternatively, we could stay on the embedded object char to indicate what's going on. 

The AT will need to know, because up to the AT to dig into the embedded object char and see if there are multiple lines in there.

Comment 6

[Aaron Leventhal]

Attachment: Fix second problem -- nested hypertexts where the inner hypertext contains multiple lines

Comment 7

[alexander :surkov (:asurkov)]

Comment on attachment 259029 [details] [diff] [review]
Fix second problem -- nested hypertexts where the inner hypertext contains multiple lines


>+  // From the descendant, go up and get the immediate child of this hypertext
>+  nsCOMPtr<nsIAccessible> childAccessible;
>+  while (descendantAccessible) {
>+    nsCOMPtr<nsIAccessible> parentAccessible;
>+    descendantAccessible->GetParent(getter_AddRefs(parentAccessible));
>+    if (this == parentAccessible) {
>+      childAccessible = descendantAccessible;
>+      break;
>+    }
>+    descendantAccessible = parentAccessible;
>+    // This offset no longer applies because the passed-in text object is not a child
>+    // of the hypertext. This happens when there are nested hypertexts, e.g.
>+    // <div>abc<h1>def</h1>ghi</div>
>+    // If the passed-in DOM point was not on a direct child of the hypertext, we will
>+    // return the offset for that entire hypertext
>+    addTextOffset = 0;
>+  }  

r=me with that it looks you don't need addTextOffset = 0 every time.

Comment 8

[Aaron Leventhal]

What's a better way so that it only is done once?

Comment 9

[Aaron Leventhal]

I'm planning to check that in as is, we can change it later if we think of a better way.