GNOME Bugzilla – Bug 543024
Important header fields for received messages not spoken when tabbing through headers in Thunderbird message view
Last modified: 2009-03-10 00:05:11 UTC
Please describe the problem: If you hit Tab or Shift-Tab in the Thunderbird message view and focus moves to the header fields, several important fields are not spoken by Orca. Over a wide variety of messages and senders, Subject and Date are spoken, but sender, addressee, and attachments fields are not spoken. This behavior occurs both when normal headers and all headers is selected from the View menu. Steps to reproduce: 1. Start Orca. 2. Start Thunderbird. 3. Open a message. 4. Pull down View menu, select headers, and select normal. 5. Press Shift-Tab several times to move through the header fields. Actual results: As focus crosses the Date and Subject fields, the contents are spoken. For all other fields, Orca is silent. Expected results: Orca should speak the contents of all of the fields. Does this happen every time? Yes. Other information: Debug log will be provided.
Created attachment 114568 [details] Debug log Log starts with Thunderbird running. A simple message containing no links is opened. Display normal headers is selected in the View menu. I pressed Tab to cycle through the header fields. Once I returned to the message body, I activated the View menu and selected all headers. I then pressed Tab repeated to cycle through all of the header, returned to the message body and, without paying enough attention :-), I continued pressing Tab through the first few headers again.
David, that sounds a lot like this bug to me. https://bugzilla.mozilla.org/show_bug.cgi?id=387838 What do you think?
I just took a look at the debug.out and created a similar one. I would say that, yes, it is the same bug. But now we are getting some additional events for objects of ROLE_UNKNOWN which I might be able to use. Closer -- and hackable I think. But what would be better and less brittle would be for Thunderbird to emit the correct events *and* associate the correct role with the accessibles in question. Therefore, given that my bug just had its first birthday four days ago, I'll look at this closer tomorrow and ping/update the Mozilla bug to see if they'll fix it.
Created attachment 114632 [details] [review] revision 1 I was working on cleaning up some old code out of the Gecko script's onFocus method when I came across this block: # If {overflow:hidden} is in the document's style sheet, we seem # to get an additional item in the hierarchy: An object of role # ROLE_UNKNOWN which is the single child of the document frame and # contains all the items which we'd expect to find in the document # frame. Under these conditions, we will get a caret-moved event # for the document frame with detail1 == 0 after a focus: event for # the object. We need to ignore both of these events else we will # jump to the top of the document. # # http://bugzilla.gnome.org/show_bug.cgi?id=412677 # https://bugzilla.mozilla.org/show_bug.cgi?id=371955 # if event.source.getRole() == pyatspi.ROLE_UNKNOWN: return While the Mozilla bug referenced was closed as WONTFIX, it seems that they've cleaned up their hierarchy somewhere else because I'm no longer seeing the ROLE_UNKNOWN with overflow:hidden. Yippee! :-) Dave, I'm sure you're thinking, what does this have to do with me? <grin> As I mentioned earlier, we are now getting focus events for the headers. The role is bogus (ROLE_UNKNOWN), but the events are there. We're just ignoring them because of the role. Since the check we were doing for the original problem no longer seems needed, I tried ripping that code out. We started speaking the headers we weren't before. I even regression tested this. It seems safe. Mind giving it a spin?
Joanie, I'm now getting the values for the header fields that weren't being spoken previously--that is, all of the addressees and the sender. However, I still don't get any labels for these fields--I have to guess as to who is the sender and who are the recipients. I'm guessing that this is because of the bogus roles. Similarly, all other values are indicated as being in a text field, but the sender and addressees are not indicated as being in a text field. Not being picky, just letting you know, since the bogus roles are likely to blame. One other thing... more from my ignorance of Thunderbird. Now that I have access to all of the fields, I don't find any field for indicating the presence of attachments. Is there such a field that I'm skipping over somehow? Or, does Thunderbird use some other method of indicating that there is an attachment if you are reading multiple messages from within the message view and, as a result, not seeing the attachment symbol in the message list.
(In reply to comment #5) > I'm now getting the values for the header fields that weren't being spoken > previously--that is, all of the addressees and the sender. However, I still > don't get any labels for these fields--I have to guess as to who is the sender > and who are the recipients. I'm guessing that this is because of the bogus > roles. Yeah, it's a goofy hierarchy. For those items (the ones we aren't speaking without this patch), the hierarchy is as follows: ROLE_LABEL with no name which has a child of ROLE_UNKNOWN whose name is the displayed email address. That UNKNOWN object happens to have a child itself of ROLE_LABEL which shares the same name. To make matters even more fun, there's no LABEL_FOR/LABELLED_BY relationship between any of those creatures and the label associated with them (e.g. "To:"). > Similarly, all other values are indicated as being in a text field, but > the sender and addressees are not indicated as being in a text field. All other values *are* in a text field (ROLE_ENTRY). Those entries also happen to have a LABELLED_BY relationship pointing back to the thing labeling them (e.g. "Subject:") When we get what we should through AT-SPI, we tend to do the right thing; when we don't, all bets are off. > One other thing... more from my ignorance of Thunderbird. Now that I have > access to all of the fields, I don't find any field for indicating the presence > of attachments. Thunderbird seems to display attachments, when they are present, in a list beneath the body of the message. I can't figure out any way to move focus to that list via the keyboard. I'm in #accessibility on irc.mozilla.org at the moment, and MarcoZ pointed me to this Mozilla bug: https://bugzilla.mozilla.org/show_bug.cgi?id=373996
I've just updated the Mozilla bug which is causing the header related issues (https://bugzilla.mozilla.org/show_bug.cgi?id=387838). In the meantime, what shall we do about the fix here?
Joanie, As I remember looking over that Mozilla bug a few days ago, the person in whose domain the problem fell was off for family leave and the bug report languished. Is there any chance that, now that you have reawakened the bug, he'll act in the next few days? As a user, something needs to be fixed before version 2.24 is released. I have been using the Thunderbird hot keys to process through a lot of mail without leaving the message view. One serious problem is determining the header information when in the message view. The best solution is the hot keys--instant access to header information--but without a fix to provide the necessary information to make a reliable key mapping, this fix seems the best way to provide access to header information in the short term. If they keep the same hierarchy but actually begin providing suitable roles, would this patch allow all of the needed information to be spoken/brailled without any further changes? My suggestion would be to apply this patch to svn and keep an eye on the mozilla bug. Any changes they make will only (one hopes) improve the information available--the behavior will not change for the user, just the information available. This wil, at least, give the user access to a limited form of the information while we wait for the needed fixes for the hot keys. Just my two cents... :-) Thanks!
Joanie, I'm OK with checking this in if you don't think it will need to be drastically changed when thunderbird gets fixed.
Sounds good guys. Thanks! Patch committed. And, to be honest, when the bug is fixed by the Mozilla guys, we shouldn't have to change anything. Orca will JustWork(tm).