Closed Bug 493723 Opened 12 years ago Closed 12 years ago

implement IAccessibleTable interface for ARIA grids

Categories

(Core :: Disability Access APIs, defect)

x86
Windows XP
defect
Not set
normal

Tracking

()

VERIFIED FIXED

People

(Reporter: surkov, Assigned: surkov)

References

(Blocks 1 open bug)

Details

(Keywords: access)

Attachments

(1 file)

16.43 KB, patch
MarcoZ
: review+
davidb
: review+
ginnchen+exoracle
: review+
Details | Diff | Splinter Review
I completely forgot we don't get IAccessibleTable implementation on IA2 side. Patch is coming out.
Attached patch patchSplinter Review
Ginn, we should do anything on ATK side to get accessible table implemented by ARIA grids like we do for IA2?
Attachment #378338 - Flags: review?(marco.zehe)
Attachment #378338 - Flags: review?(ginn.chen)
Attachment #378338 - Flags: review?(david.bolter)
I think implementing nsIAccessibleTable is enough.

See:
490       //nsIAccessibleTable
491       nsCOMPtr<nsIAccessibleTable> accessInterfaceTable;
492       QueryInterface(NS_GET_IID(nsIAccessibleTable),
493                      getter_AddRefs(accessInterfaceTable));
494       if (accessInterfaceTable) {
495           interfacesBits |= 1 << MAI_INTERFACE_TABLE;
496       }
Attachment #378338 - Flags: review?(ginn.chen) → review+
(In reply to comment #2)
> I think implementing nsIAccessibleTable is enough.

Thank you, that was I thought of.
Can someone explaing a little more about what this patch is fixing?
(In reply to comment #4)
> Can someone explaing a little more about what this patch is fixing?

It adds implementation of IAccessibleTable interface on aria grid by introducing wrap class inherited from CAccessibleTable class.
Attachment #378338 - Flags: review?(marco.zehe) → review+
Attachment #378338 - Flags: review?(david.bolter) → review+
checked in, http://hg.mozilla.org/mozilla-central/rev/2928cc356e14
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Note the windows unit test bustage was eventually starred, but we should resolve the sr bustage before re-commit. Marco what are the steps to reproduce the bustage?
Really it looks like bug 486489. Marco what does it make you think it's our failure? Btw, I didn't get about screen reader. Do you mean tinderbox machine has running screen readers on windows?
Right, that was the leak on tinderbox, but Marco locally pin-pointed this patch causes crashed a screen reader use case. The real problem might not be our fault, but is perhaps discovered by your patch.
(In reply to comment #10)
> Right, that was the leak on tinderbox, but Marco locally pin-pointed this patch
> causes crashed a screen reader use case. The real problem might not be our
> fault, but is perhaps discovered by your patch.

Would be nice to have stack trace then
Here's the story:
1. I did a local build with the patch included.
2. With NVDA running, Started it.
3. Went to a website like www.google.com, which has NO tables, it came up fine.
4. Opened ChatZilla, which I had installed.
5. Pressed F6 to go into the output window, which has tables.

NVDA and Firefox crashed.

6. Performed the same with JAWS. No crash, but the virtual buffer from that point on had no contents, even when closing ChatZilla, the previously loaded page that was OK now was blank in the virtual buffer.

7. I backed out the patch from this bug, and the problem was gone.
(In reply to comment #11)
> (In reply to comment #10)
> > Right, that was the leak on tinderbox, but Marco locally pin-pointed this patch
> > causes crashed a screen reader use case. The real problem might not be our
> > fault, but is perhaps discovered by your patch.
> Would be nice to have stack trace then

Could either of you try that? The problem is that with debug sessions, I'm left in the dark once the debugger comes up and halts Firefox, because of the in-process solutions of all the screen readers. My steps above are reproducible 100% of the time here.
Unfortunately I can't reproduce this. Also I don't see role="grid" nor "treegrid" in chatzilla sources and therefore I don't know how this patch can affect on chatzilla.
It uses role="log" on the table. For reproduction it is enough to folow the steps I took above.
(In reply to comment #15)
> It uses role="log" on the table. For reproduction it is enough to folow the
> steps I took above.

role="log" doesn't use nsARIAGridAccessible what is changed in this patch. I tried your steps. Where do you get chatzilla?
(In reply to comment #16)
> (In reply to comment #15)
> > It uses role="log" on the table. For reproduction it is enough to folow the
> > steps I took above.
> 
> role="log" doesn't use nsARIAGridAccessible what is changed in this patch. I
> tried your steps. Where do you get chatzilla?

Actually I think you're right. We could create nsARIAGridAccessible for table role="log" because of bug 498277. What nvda version do you use?
I use the snapshot builds of NVDA that are made available on a daily basis. Also, this reproduces with JAWS 10.0.1151 (current release).
(In reply to comment #18)
> I use the snapshot builds of NVDA that are made available on a daily basis.
> Also, this reproduces with JAWS 10.0.1151 (current release).

Can't reproduce with NVDA r2995, JAWS 10.0.1142U. Will try with new JAWS.
Depends on: 498277
Marco, can't reproduce with JAWS 10.0.1151.
Relanded:
http://hg.mozilla.org/mozilla-central/rev/c8f747e36853.

Appears my local build was busted, can no longer reproduce. Sory for the noise!
Status: REOPENED → RESOLVED
Closed: 12 years ago12 years ago
Resolution: --- → FIXED
Verified fixed in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090618 Minefield/3.6a1pre (.NET CLR 3.5.30729)
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.