623445 - IAccessibleHypertext::hyperlinkIndex out of order

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[Michael Curran]

User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101214 Firefox/4.0b8pre
Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101214 Firefox/4.0b8pre

If the DOM is mutated in such a way that causes an extra embedded object character to be inserted in IAccessibleText::text before other embedded object characters,  the hyperlink indexes (from IAccessibleHypertext::hyperlinkIndex) for the added embedded object character and subsiquent existing embedded object characters is rather incorrect.
 An Example html file is attached.
This file contains a document with a button, a paragraph (with a display style of None), and two links (A and B) separated by a space. The button if clicked changes the display style of the hidden paragraph to block.
Before pressing the button, the output from IAccessibleText::text on the document (with offsets of 0 and -1) is:
XX X
(Where the Xs represent the embedded object characters)
Calling IAccessibleHypertext::hyperlinkIndex on all offsets respectivly yields:
0,1,-1,2
(button,link A,?,link B)

If you then click the button, IAccessibleText::text looks like:
XXX X
(which seems correct)
But IAccessibleHypertext::hyperlinkIndex yields:
0,-1,1,2,-1
(button,?,shown paragraph,link A,?)
However, if you collect up to nCharacters+1 instead of just nCharacters, you get:
0,-1,1,2,-1,3
(button,?,shown paragraph,link A,?,link B)
I think, that the output (just using nCharacters again) should be:
0,1,2,-1,3
(button,shown paragraph,link A,?,link B)

So what Gecko seems to be doing:
Starting with:
XX X
0,1,-1,2

Then changing to:
XXX X
(adding the second x)
Gecko makes it:
0,1,2,-1,3
(Adding the second hyperlink as 1 and incrementing the rest by 1)
But then (strangely) also adding a -1 at the place of the new embedded object, yielding:
0,-1,1,2,-1,3

A part from this just being wrong, this causes an AT such as NVDA to not render particular things in its virtualBuffer.
In this example: clicking the button makes NVDA  only render the button and the newly shown paragraph, but not either of the two links. The reason for this is because the addition of that -1 has pushed all the hyperlink indexes off by 1 place, which as meant that the A link is now over the space (NVDA does n't ask hyperlinkIndex on anything other than embedded object characters), and the B link is now off the end (nCharacters+1) (NVDA of course only collects up to nCharacters).


Reproducible: Always

Steps to Reproduce:
1. Open the attached testcase in Firefox 4.
2. Start NVDA and place focus in the opened document.
3. Note that NVDA's virtualBuffer contains a "show" button, and two links: "A" and "B" separated by a space.
4. Press the "show" button.
Actual Results:  
NVDA's virtualBuffer now contains a "show" button, a "hidden paragraph" paragraph, a space, but no links.

Expected Results:  
NVDA's virtualBuffer should contain a "show" button, a "hidden paragraph" paragraph, two links (A and B) separated by a space.

Comment 1

[Michael Curran]

Attachment: Testcase that can show incorrect hyperlinkIndex.

Comment 2

[Marco Zehe (:MarcoZ)]

This is definitely confirmed, and this is also NOT, repeat, NOT fixed by bug 498015. At least that latest try-server build also exposes the bug as well as a current nightly.

This is a regression from Firefox 3.6, most probably a fall-out from bug 570275.

Fer, I suspect you'll be able to see the same problematic behavior when testing the testcase on Linux. The Hyperlink indexing is part of nsHyperTextAccessible and thus platform independent code.

Comment 3

[David Bolter [:davidb] (NeedInfo me for attention)]

Regression, blocking. Assigning to Fer for a first look.

Comment 4

[Fernando Herrera]

Confirmed, same results in linux. Looking at the code.

Comment 5

[alexander :surkov (:asurkov)]

Can't reproduce on my local build (applied bug 498015):

Code snippet executed in DOMi:
output(accessible.getText(0, -1));
var count =accessible.characterCount; 
output("\n" + count + "\n");
for (var idx = 0; idx < count; idx++) {
  output(accessible.getLinkIndexAtOffset(idx) + ", ");
}

initial output:
 
4
0, 1, -1, 2, 

result output:
 
5
0, 1, 2, -1, 3, 

Nightly build's results output:

 
5
0, -1, 1, 2, -1, 

seems to be fixed by 498015

Comment 6

[Fernando Herrera]

I cannot test it because the patch for bug #498015 is segfaulting here

Comment 7

[Fernando Herrera]

Ok, tested now, and patch at bug #498015 fixes this issue.

Comment 8

[David Bolter [:davidb] (NeedInfo me for attention)]

Fernando, can you verify this is fixed on trunk and close?

Comment 9

[Fernando Herrera]

Yes, fixed on trunk.