604560 - IAccessibleText::get_text skipping embedded objects

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[James Teh [:Jamie]]

On the URL provided, just after the page loads, NVDA seems to render the content. However, before it can be navigated, the content disappears from the buffer. Refreshing the buffer or restarting NVDA does not help; the buffer remains completely blank. I've tracked this down to IAccessibleText::get_text() not returning an embedded object character, which happens to correspond to the embedded object containing the entire content of the page.

Str:
1. Open the URL provided.
2. Wait about 10 seconds to be sure it has settled.
3. Examine the children of the tab document accessible, as well as their grandchildren.
Result: There are three children: an invisible iframe (id "a2apage_sm_ifr") with no children, an invisible section (div with no id) with no children and a visible section (div with id of "page") with some children.
4. Call IAccessibleText::get_nCharacters on the tab document accessible.
Result: 3.
5. Call IAccessibleText::get_text with offsets of 0 and 3.
Expected: Three embedded object characters.
Actual: Only two embedded object characters.
Observation: Even if one of the objects was skipped due to being invisible, nCharacters should reflect this.
6. Retrieve the embedded object at offset 0 using IAccessibleHypertext and QI to IAccessible2.
Result: This is the invisible iframe (id "a2apage_sm_ifr").
7. Retrieve the embedded object at offset 1 using IAccessibleHypertext and QI to IAccessible2.
Result: This is the invisible section (div with no id).

Problem: There are no more embedded objects to retrieve according to IAccessibleText::get_text, but we haven't seen the content div yet (id of "page"), hence the blank buffer.

Interestingly, if you retrieve the accessible for the embedded object at offset 2, you do get the "page" div. However, as noted, we don't do this because get_text didn't report an embedded object character for it.

Note that in Firefox 3.6 (where this works fine), there are only two children and two embedded object characters. The invisible div with no id is not exposed.

Comment 1

[alexander :surkov (:asurkov)]

request blocking status, regression, prevents NVDA to expose content under certain circumstances

Comment 2

[James Teh [:Jamie]]

For reference, original NVDA issue ticket: http://www.nvda-project.org/ticket/951

Comment 3

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

Does this happen with builds from bug 570275?

Comment 4

[James Teh [:Jamie]]

(In reply to comment #3)
> Does this happen with builds from bug 570275?
Can't repro with the last try build from bug 570275. Interestingly, in that build, the children of the document are different. There is the invisible div, an invisible text node, the visible div and another invisible text node. There is no invisible iframe. Note that this try build was made before the build with which I originally tested, so I can't be 100% certain yet that bug 570275 fixes the issue.

Comment 5

[alexander :surkov (:asurkov)]

Jamie, I tested this bug few days ago with local build containing the fix of bug 570275, and I saw the same structure. These invisible text nodes (containing no text) are exposed in accessible children but they do not participate in text interface. I don't why are they exposed but it's interesting to know whether this is a problem for NVDA?

Comment 6

[James Teh [:Jamie]]

(In reply to comment #5)
> Jamie, I tested this bug few days ago with local build containing the fix of
> bug 570275, and I saw the same structure. These invisible text nodes
> (containing no text) are exposed in accessible children but they do not
> participate in text interface. I don't why are they exposed but it's
> interesting to know whether this is a problem for NVDA?
No, the invisible text nodes are not a problem. I only mentioned them because this is different to what is exposed in a current nightly.

Comment 7

[alexander :surkov (:asurkov)]

Ok, thanks. The presence of these nodes is ugly because they don't appear if NVDA isn't running what means we're not intended to create accessibles for them but we do under some tricky circumstances.

Comment 8

[James Teh [:Jamie]]

(In reply to comment #4)
> Can't repro with the last try build from bug 570275.
Nor the newer build from bug 570275 comment #112. Nice. Bug still exists in the current nightly.
> Interestingly, in that
> build, the children of the document are different. There is the invisible div,
> an invisible text node, the visible div and another invisible text node. There
> is no invisible iframe.
Still the same.
> Note that this try build was made before the build with
> which I originally tested, so I can't be 100% certain yet that bug 570275 fixes
> the issue.
I assume the new build is based on current trunk, so yes, we can be certain now. :)

Comment 9

[alexander :surkov (:asurkov)]

(In reply to comment #8)

> > Note that this try build was made before the build with
> > which I originally tested, so I can't be 100% certain yet that bug 570275 fixes
> > the issue.
> I assume the new build is based on current trunk, so yes, we can be certain
> now. :)

I'm not sure whether try server build applies against the trunk, but anyway it must be not earlier than Sat, 16 Oct 2010.

Comment 10

[alexander :surkov (:asurkov)]

I think it makes sense to deal with these invisible text nodes we expose, to understand why are they created while NVDA running. But this bug taking into account its summary is fixed by bug 570275. Perhaps the summary should be changed and bug keep open until investigations. I'm not sure whether it should stay blocking.

Comment 11

[James Teh [:Jamie]]

Imo, this should be closed as fixed by bug 570275 and a spin-off opened to investigate the invisible text nodes. My reasoning is that this bug was filed due to a rather severe problem which caused broken functionality and that has now been fixed. In contrast, the invisible text nodes are just an oddity that needs investigation and do not affect functionality.

Comment 12

[alexander :surkov (:asurkov)]

Ok, I filed bug 606108 for text accessible problem.

resolved as fixed by bug bug 570275