493723 - implement IAccessibleTable interface for ARIA grids

Status: VERIFIED FIXED

(Core :: Disability Access APIs, defect)

Description

[alexander :surkov (:asurkov)]

I completely forgot we don't get IAccessibleTable implementation on IA2 side. Patch is coming out.

Comment 1

[alexander :surkov (:asurkov)]

Attachment: patch

Ginn, we should do anything on ATK side to get accessible table implemented by ARIA grids like we do for IA2?

Comment 2

[Ginn Chen]

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       }

Comment 3

[alexander :surkov (:asurkov)]

(In reply to comment #2)
> I think implementing nsIAccessibleTable is enough.

Thank you, that was I thought of.

Comment 4

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

Can someone explaing a little more about what this patch is fixing?

Comment 5

[alexander :surkov (:asurkov)]

(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.

Comment 6

[alexander :surkov (:asurkov)]

checked in, http://hg.mozilla.org/mozilla-central/rev/2928cc356e14

Comment 7

[Marco Zehe (:MarcoZ)]

Had to back out because of screen reader and Windows unittest bustage:
http://tinderbox.mozilla.org/showlog.cgi?tree=Firefox&errorparser=unittest&logfile=1244807588.1244815069.25678.gz&buildtime=1244807588&buildname=WINNT%205.2%20mozilla-central%20unit%20test&fulltext=1

Comment 8

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

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?

Comment 9

[alexander :surkov (:asurkov)]

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?

Comment 10

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

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.

Comment 11

[alexander :surkov (:asurkov)]

(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

Comment 12

[Marco Zehe (:MarcoZ)]

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.

Comment 13

[Marco Zehe (:MarcoZ)]

(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.

Comment 14

[alexander :surkov (:asurkov)]

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.

Comment 15

[Marco Zehe (:MarcoZ)]

It uses role="log" on the table. For reproduction it is enough to folow the steps I took above.

Comment 16

[alexander :surkov (:asurkov)]

(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?

Comment 17

[alexander :surkov (:asurkov)]

(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?

Comment 18

[Marco Zehe (:MarcoZ)]

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).

Comment 19

[alexander :surkov (:asurkov)]

(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.

Comment 20

[alexander :surkov (:asurkov)]

Marco, can't reproduce with JAWS 10.0.1151.

Comment 21

[Marco Zehe (:MarcoZ)]

Relanded:
http://hg.mozilla.org/mozilla-central/rev/c8f747e36853.

Appears my local build was busted, can no longer reproduce. Sory for the noise!

Comment 22

[Marco Zehe (:MarcoZ)]

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)