Closed Bug 363646 Opened 15 years ago Closed 15 years ago
message header tree table report incorrect number of table headers
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
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.
This bug is related to Bugzilla Bug 356347 (https://bugzilla.mozilla.org/show_bug.cgi?id=356347). See comments #25 and #27.
It's a bug about xul tree table. changing component to core, disable access API
Component: Mail Window Front End → Disability Access APIs
Product: Thunderbird → Core
Version: unspecified → Trunk
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 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.
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 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".
Attachment #248727 - Flags: review?(mano)
Comment on attachment 248727 [details] [diff] [review] patch it's used in nsTreeSorting.js.
Attachment #248727 - Flags: review?(mano) → review-
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.
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?
(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.
(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 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.
Attachment #248727 - Flags: superreview?(neil) → superreview+
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
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.