1268916 - a table from bugzilla's tracking flags is not rendered in NVDA

Status: RESOLVED WORKSFORME

(Core :: Disability Access APIs, defect)

Description

[alexander :surkov (:asurkov)]

From bug 1268677, Marco's comment:

Observation with the try server build on this bug 1268677:
Until recently, there was a bug in Firefox that affected the table containing the tracking flags on a Bugzilla bug like this one. Initially, that table is hidden. Once you click the Edit link next to the "Tracking Flags:" text, the table gets inserted into the accessibility tree that contains all of those tracking flags. A table with about 20 rows or so. When this happened, NVDA's virtual buffer always needed a refresh to see that table. Other dynamic insertions were no problem, just this particular one. So the steps were, with NVDA running:

1. Find the Edit link next to the "Tracking Flags:" text, and press Enter on it.
2. Notice that the table wasn't there that actually contained these flags.
3. Press NVDA+F5 to refresh the virtual buffer.

Result: Table below the "Tracking Flags:" text was now present.

After bug 1255009 and bug 1261425 landed, this bug went away. The table would now always appear right below the text without NVDA needing a refresh of the virtual buffer.

With the patch on this bug 1268677 now, the bug returns, but even stronger, because not even a virtual buffer refresh will now make that particular table visible. Again, it is the table that gets inserted when you click the Edit link next to the "Tracking Flags:" text when initially bringing up this bug.

Perhaps this patch can be expanded to address this particular bug, since it seems very very closely related?

Comment 1

[alexander :surkov (:asurkov)]

A cell containing that 'edit' link has tree:
cell
  textleaf (
  edit link
  textleaf )
  table

After the edit link is clicked then, the tree is
cell
  table

If table is not rendered by NVDA at all, then there's something wrong with out text/link properties. I tried various one in DOMInspector:

var a = accessible;
var t = a.getText(0, -1);
output(`text len: ${t.length}\n`);
output(`is it an embed char: ${t.charCodeAt(0) == 65532}\n`);
output(`link count: ${a.linkCount}\n`);
var l = a.getLinkAt(0).QueryInterface(Components.interfaces.nsIAccessible);
output(`link role: ${l.role}\n`);
output(`link start and end offsets: ${l.startIndex}, ${l.endIndex}\n`);
output(`link index: ${a.getLinkIndex(l)}\n`);
output(`link index at 0 offset: ${a.getLinkIndexAtOffset(0)}\n`);
output(`link index at 1 offset: ${a.getLinkIndexAtOffset(1)}\n`);

which gave me:

text len: 1
is it an embed char: true
link count: 1
link role: 24
link start and end offsets: 0, 1
link index: 0
link index at 0 offset: 0
link index at 1 offset: 0

So everything looks ok so far.

Jamie, could you look at your side please?

Comment 2

[Marco Zehe (:MarcoZ)]

NI'ing Jamie for comment #1.

Comment 3

[Marco Zehe (:MarcoZ)]

This was fixed by bug 1268069. Closing as WORKSFORME.

Comment 4

[alexander :surkov (:asurkov)]

(In reply to Marco Zehe (:MarcoZ) from comment #3)
> This was fixed by bug 1268069. Closing as WORKSFORME.

awesome, thanks for checking it out