User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1) Gecko/20060601 Firefox/2.0 (Ubuntu-edgy) Build Identifier: version 3 alpha 1 (20061112) This is an accessibility problem. The subscribe dialog contains a tree table with a row for each mail folder to subscribe to. The right-hand table cell contains a checkbox indicating whether the mail folder is subscribed to. The problem is the AccessibleState for the checkbox does not indicate whether the box is checked or unchecked. This means an assistive technology like Orca cannot present the state of the checkbox, that is, whether the folder is subscribed to or not. Reproducible: Always Steps to Reproduce: 1. Start Thunderbird 3.0 and launch the subcribe File->Subscribe dialog 2. Start at-poke and expand the Thunderbird subscribe dialog 3. Compare the AccessibleState of the checkbox table cells. Notice that the state is the same, whether the checkbox is checked or not. Actual Results: see above. Expected Results: The AccessibleState should indicate whether the checkbox is checked or not. The checkbox table cells have an "Activate" AccessibleAction. Is this the same as the "Toggle" AccessibleAction? In other words, does it check and uncheck the checkbox?

confirmed.

This appears to be the problem in bug 312457, correct?

Marking as dependency instead of duplicate until we know for certain that the other bug fixes this one.

crossplatfor fix in firefox side is easy. just |= STATE_CHECKABLE for all checkable item. including checkbox, checkable list item, checkable menuitem atk support is needed, see http://bugzilla.gnome.org/show_bug.cgi?id=399295

Nian, how is this not a duplicate of bug 312457 -- the bug Mike mentions in comment 2?

I believe this bug (and also bug 312457) was addressed in bug 365866.

This is a duplicate of the bug I previously submitted bug 365866.

Okay, just mark it as such (or do we need to get you "editbugs" permissions)

I'm reopening this bug because the fix for bug 365866 doesn't seem to have fixed this one. Several observations: 1. Looking at the table cells in this dialog, if you select an item -- whether it is checked or unchecked -- the following states are present: * enabled * focusable * focused * opaque * selectable * selected * sensitive * showing * vertical * visible Thus we cannot distinguish checked from unchecked via state. 2. Using Accerciser's event monitor to monitor events, pressing the space bar to toggle the state results in no events whatsoever. 3. There is no accessible name present for the cell that contains the checkbox (which, if I understand the comments in bug 365866 correctly was the fix). 4. There is no action that even hints at these items being toggle-able. The only action exposed is activate which merely causes that row to become selected. Sorry and thanks!!

Joanmarie for finding this and reopening it. I think the problem here is that under the hood, these aren't checkboxes, but probably are instead XUL cyclers. If they were checkboxes they should just work. XUL cyclers can have 2 or more states and our general solution can't assume only two states (namely checked or not). I think perhaps we should really push for cyclers that are pretending to be checkboxes be reimplemented using XUL checkboxes. In the meantime... what to do? I guess this will need a bug 365866 type of solution until then. So we'll need to implement GetCellValue in the tree view for the subscribe dialog to return a sensible string like "subscribed" to correspond to the checked state.

Make that "Joanmarie, thanks for..."

Orca bug 468551 may be related to this bug: http://bugzilla.gnome.org/show_bug.cgi?id=468551. However, what we're dealing with is the problem where no such state 'checkable' exists in the AT-SPI. So, when we deal with things of role table cell, we try to infer something is a checkbox by querying its actions for a "toggle" action. If we see that, we infer it is a checkbox. If I understand it correctly, bug 368012 seems to have exposed an object attribute "checkable" = "true". So, maybe Orca look for that in addition to looking for the "toggle" action.

Yes that should work to tell you if it is checkboxy, but I'm not sure if you will know the 'checked' state?

My understanding is that we'd get one of the following: nothing (meaning not checked), CHECKED, or INDETERMINATE. Is that wrong?

OK I'm looking at this quickly now (I shouldn't be... shhh). Using accerciser it seems these table cells are reported as cells, with an appropriate name for the first cell in each row but that's about where it stops. I don't see anything (including in the attributes) that would tell me this is checkable/toggleable. I'll need to look deeper but I think these are probably just text cells with onclick handlers... not actually meaningful real widgets. We'll need to reimpl using proper xul widgets or customize accessibility for this table. In fact here is a row in the subscription table: table cell: foo , table cell: [no name] Both cells seem to expose an 'activate' action but neither work. Basically it is just not accessible and needs custom work. Sorry it took me a while to get around to investigating this. (Note while this appears to be a duplicate of bug 365866, under the hood it will be a different fix.)

> Basically it is just not accessible and needs custom work. Yep. That looks like exactly what it is. :-(

Should we consider reassigning this bug to someone else? I think the current assignee might be off to other things.

(In reply to comment #17) > Should we consider reassigning this bug to someone else? I think the current > assignee might be off to other things. > Is the bug still valid? Can anybody confirm it?

I can. Nothing's changed I'm afraid. My comment #9 stands as is. I'm still getting used to Accessibility Probe, but I have a shiny new virtual Vista box with thunderbird from trunk, Accessibility Probe, and JAWS 9.0. :-) Here's what I can tell you: 1. JAWS doesn't say a thing when you toggle the state of these items. 2. Accessibility Probe's EventMonitor doesn't show any events when you toggle the state of these items. Sadly, when I attempt to examine the hierarchy in Accessibility Probe I can get this far: - [...] - grouping - tabFolder - propertyPage[1] - tree[1] - propertyPage[1] - tree[1] - pushButton[@accessibleName='Subscribe'] - [...] Based on the highlight rectangle, the items in question are children of the tree[1]. (Why I have two of them, I could not tell you.) I cannot drill down into the tree to see the items (and hence their states). Because my familiarity with Accessibility Probe is extremely limited (read about 1/2 an hour), this could easily be user error. (Update: I'm in #accessibility and MarcoZ doesn't see them either.) Regardless, I would hope to see an event for them here (I do see EVENT_OBJECT_FOCUS and EVENT_OBJECT_SELECTIONWITHIN when I arrow among the treeItems; but nothing when I press space bar to toggle the state). Thanks!

Joanie, do I get the bug right: we won't fire state changed event when checkbox is checked/unchecked? because bug summary is bit different. If I'm right then we should provide action interface to AT (getActionName, getActionCount, doAction) as well?

Alexander you're correct that there are no state changed events fired. In addition: When examining the state of the current item, there's nothing in the list of states to indicate that a checked item is checked. (See comment #13 and comment #14 and comment #15). Also: As David points out (comment #15), there is an associated action (activate) but it doesn't work. (This I forgot to re-verify, and my development box is running regression tests atm, but I can look at that tomorrow). Lastly, I think comment #16 reflects the current situation: > > Basically it is just not accessible and needs custom work. > > Yep. That looks like exactly what it is. :-( I suppose there's no chance of just replacing these checkbox-like objects with actual checkboxes is there? ;-) If not, and you can address the above issues, that would be great! Thanks so much Alexander!

Any word on this one? Thanks!!

We'll get to this when we deal with the Thunderbird specific ones after FF 3 ships.

Ping. :-)

In the meantime we should have two problems 1) no state events 2) no actions work Checked state should exposed correctly on linux and it should be correctly exposed on windows if checkbox column is primary.

fixed in bug 503727

Was this bug ever actually confirmed as fixed? Using Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.2pre) Gecko/20100214 Lanikai/3.1b1pre, I'm still not able to see checkable/checked/unchecked on the tree items or table cells in the Subscribe dialog. Furthermore, I don't ever remember seeing this working. Is this a regression or should it be reopened?

Same for the tree in the "Items for Offline Use" dialog (ID: synchronizeTree).

(In reply to comment #28) > Was this bug ever actually confirmed as fixed? Using Mozilla/5.0 (Windows; U; > Windows NT 6.1; en-US; rv:1.9.2.2pre) Gecko/20100214 Lanikai/3.1b1pre, I'm > still not able to see checkable/checked/unchecked on the tree items or table > cells in the Subscribe dialog. Furthermore, I don't ever remember seeing this > working. Is this a regression or should it be reopened? I don't remember seeing it working either.

It sounds like thunderbird bug. The subscribedColumn (subscribe.xul dialog) has text type. It should have checkbox type to be picker by a11y correctly.

(In reply to comment #31) > It sounds like thunderbird bug. The subscribedColumn (subscribe.xul dialog) has > text type. It should have checkbox type to be picker by a11y correctly. Blake, could you look at this, please, perhaps, cc people who can fix this?

I've taken a look, but there doesn't seem to be anyone in particular who could fix this. (At least, no-one better than you. ;) Have you tried just adding type="checkbox" to the subscribedColumn, and see if that works? I would be happy to review a patch along those lines… Thanks, Blake.

Taking a stab at it.

OK, after looking at this for a bit and talking to Bwinton, I'm bailing out after all. This is RDF and such stuff. Simply setting type="checkbox" on the column does give me a state, but it iss always unchecked, regardless of the actual description status. So the mechanism to check/uncheck this somehow bypasses everything knwn to the a11y APIs about tree tables, and probably only gives a visual representation of the state. Giving this back to the general since this is beyond my capabilities and cycles ATM. Blake suggests to look at mail/base/content/subscribe.xul line 144-ish.

Hey Marco, I chatted with David Bolter, and came up with this. I have no idea what it's going to do from an accessibility standpoint, but it looks okay on Mac, and so if you could test it out and let me know if it works, I would appreciate it. (I'll be happy to run try-server builds for you, if you'ld like.) Thanks, Blake.

Comment on attachment 530130 [details] [diff] [review] Just a thought I had… This works! It gibes me "true" or "false" for subscribed/non-subscribed items. It also now shows the checked/unchecked state inside the second column. f=me.

Comment on attachment 530130 [details] [diff] [review] Just a thought I had… And the try-server runs look pretty good (rev:b81046ad586b on http://build.mozillamessaging.com/tinderbox/showbuilds.cgi?tree=ThunderbirdTry), so I'll ask for review from… Uh… Magnus, maybe? I have no idea who owns this code… Thanks, Blake.

Comment on attachment 530130 [details] [diff] [review] Just a thought I had… Looks ok to me! r=mkmelin

Committed as http://hg.mozilla.org/comm-central/rev/fd9cb27c8519

Thank you, guys, for fixing this.

Verified fixed in Miramar 3.3a4pre (2011-05-10). BTW how do I get the whole build ID out of Miramar now that you've switched to the new About window?

I believe Help -> Troubleshooting Information has the build id.

Yes, the full build ID is Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0a2) Gecko/20110510 Thunderbird/3.3a4pre