363646 - message header tree table report incorrect number of table headers

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[Lynn Monsanto]

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 (20061211)

There are 16 possible column headers. By default, Thunderbird displays 8 of them.

1. Threads
2. Starred
3. Attachments
4. Subject
5. Read
6. Sender
7. Junk Status
8. Date

The problem is that the column header information is wrong. For the default settings:

- The column count is reported to be 3, when it should be 8
- Only the following headers are reported: Subject, Sender and Date. Note these are just the headers containing text. 

This is a serious problem because the column count is used to determine the row and column for the cell as a specified index.  Assistive technologies cannot determine which cells belong to each column and row. In particular, Orca cannot speak the cells in a mail header row correctly, because it cannot get the actual cells in a given row.

Reproducible: Always

Steps to Reproduce:
1. Enable assistive technologies on the desktop.
2. Start Thunderbird 3
3. Start at-poke and view the treetable containing the message headers. You will see that the column count is incorrect, and the header list only contains headers with text.

Actual Results:  
See Details above.

Expected Results:  
All of the message table headers should be returned by the AT-SPI

Comment 1

[David :Bienvenu]

I don't know anything about this, but there are three columns with text in them - could that be involved? Cc'ing David, who's working on accessibility issues for TB.

Comment 2

[Lynn Monsanto]

This bug is related to Bugzilla Bug 356347 (https://bugzilla.mozilla.org/show_bug.cgi?id=356347). See comments #25 and #27.

Comment 3

[Evan Yan]

It's a bug about xul tree table. changing component to core, disable access API

Comment 4

[Evan Yan]

Attachment: patch

1) add nsIAccessibleProvider implementation for treecol-image;

2) replace treecol's attribute "display" with "label".
"display" attribute makes the accessible object's name fall back to "tooltiptext", and I don't see treecol has an attribute names "display".

Comment 5

[Aaron Leventhal]

Comment on attachment 248727 [details] [diff] [review]
patch

Should we just support the display attribute since it's a part of XUL?  Take a look at the definition of that attribute, but I believe other trees will use it, and we need to change an nsIAccessible::GetName() impl somewhere to support it.

Today's my last day before vacation, so please get Ginn Chen and a toolkit peer to review this.

Comment 6

[Willie Walker]

I don't know what the 'display' attribute is, so I'll just comment with the main use case we're trying to support: when the user arrows between column in the message header list in Thunderbird, Orca will let them know which column they are in by speaking the column header.  The column header should be a brief descriptive name, such as the names listed in the initial comment for this bug report.  Falling back to making the name be the long tooltip text would end up causing things to be way too verbose and is suboptimal.

Thanks, and have a great vacation!  I'll be scrooging away until the bitter end.

Comment 7

[Evan Yan]

Comment on attachment 248727 [details] [diff] [review]
patch

mano, does "display" attribute in tree-col have any specific meaning?
I checked in xulplanet.com, and didn't find tree-col has any attribute named "display".

Comment 8

[Asaf Romano (gone)]

Comment on attachment 248727 [details] [diff] [review]
patch

it's used in nsTreeSorting.js.

Comment 9

[Evan Yan]

mscott,

does "display" attribute does something different from "label" attribute? do you think we can replace "display" with "label"?

as Mano and I talked at irc, for nsTreeSorting.js speaking, it's safe to replace. but we're not sure whether there is any side effect with the replacement.

Comment 10

[Scott MacGregor]

I don't know what the display attribute is used for. In this case, we are using it for thread pane columns that use icons instead of label text. If you changed the display to a label, does the tree column still render correctly or do we try to show the label? 

Comment 11

[Evan Yan]

(In reply to comment #10)
> I don't know what the display attribute is used for. In this case, we are using
> it for thread pane columns that use icons instead of label text. If you changed
> the display to a label, does the tree column still render correctly or do we
> try to show the label? 
> 
yes, the tree column still render the image correctly, and the popup menu of column picker also display the column name correctly.

Comment 12

[Scott MacGregor]

(In reply to comment #11)
> (In reply to comment #10)
> > I don't know what the display attribute is used for. In this case, we are using
> > it for thread pane columns that use icons instead of label text. If you changed
> > the display to a label, does the tree column still render correctly or do we
> > try to show the label? 
> > 
> yes, the tree column still render the image correctly, and the popup menu of
> column picker also display the column name correctly.
> 

then I'm ok with trying to switch the display attribute to label for the tree cols. It couldn't hurt to ask Neil Endeakin if he remembers what the display attribute is used for too though.

Comment 13

[[e-mail]]

Comment on attachment 248727 [details] [diff] [review]
patch

>+    <implementation implements="nsIAccessibleProvider">
sr=me if you merge this and the other tree column binding by moving the code to the treecol-base binding.

Comment 14

[Ginn Chen]

Checking in toolkit/content/widgets/tree.xml;
/cvsroot/mozilla/toolkit/content/widgets/tree.xml,v  <--  tree.xml
new revision: 1.41; previous revision: 1.40
done
Checking in mail/base/content/messenger.xul;
/cvsroot/mozilla/mail/base/content/messenger.xul,v  <--  messenger.xul
new revision: 1.66; previous revision: 1.65
done
Checking in mail/base/content/SearchDialog.xul;
/cvsroot/mozilla/mail/base/content/SearchDialog.xul,v  <--  SearchDialog.xul
new revision: 1.22; previous revision: 1.21
done
Checking in mailnews/base/resources/content/threadPane.xul;
/cvsroot/mozilla/mailnews/base/resources/content/threadPane.xul,v  <--  threadPane.xul
new revision: 1.135; previous revision: 1.134
done

Comment 15

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1527381