IAccessibleHypertext::hyperlinkIndex out of order

RESOLVED FIXED

Status

()

defect
RESOLVED FIXED
9 years ago
9 years ago

People

(Reporter: mick, Assigned: fherrera)

Tracking

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(blocking2.0 final+)

Details

(Whiteboard: [softblocker])

Attachments

(1 attachment)

Reporter

Description

9 years ago
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.
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Version: unspecified → Trunk
Regression, blocking. Assigning to Fer for a first look.
Assignee: nobody → fherrera
blocking2.0: --- → final+
OS: Windows 7 → All
Hardware: x86 → All

Updated

9 years ago
Whiteboard: [softblocker]
Assignee

Comment 4

9 years ago
Confirmed, same results in linux. Looking at the code.
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
Depends on: 498015
Assignee

Comment 6

9 years ago
I cannot test it because the patch for bug #498015 is segfaulting here
Assignee

Comment 7

9 years ago
Ok, tested now, and patch at bug #498015 fixes this issue.
Fernando, can you verify this is fixed on trunk and close?
Assignee

Comment 9

9 years ago
Yes, fixed on trunk.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.