GNOME Bugzilla – Bug 535184
Focused object not spoken in Thunderbird at program start
Last modified: 2008-06-23 15:15:47 UTC
Please describe the problem: When Thunderbird is started, the window appears but the focused object is not vocalized. As a result the user doesn't know where they are in the program. Steps to reproduce: 1. Start Thunderbird. 2. Enter account passwords. 3. Listen to output. Actual results: The title for the frame is spoken followed by the word "frame", then Orca is silent. Expected results: The title of the frame is spoken, followed by the name of the object that currently has focus within the program. Optimally, this would be the selected element of the list of email messages. Does this happen every time? Yes. Other information:
We'll shoot for 2.24.0 for this one. Thanks for reporting this problem!
Created attachment 113140 [details] Orca debug log generated whilst testing this problem. I believe David is describing the problem when you run Thunderbird for the very first time (i.e. there is no ~/.thunderbird directory already present). In this situation an Account Wizard is displayed. You can see the "window:activate" event at line 535. From that we speak all the labels that don't label anything: SPEECH OUTPUT: 'Account Wizard New Account Setup In order to receive messages, you first need to set up a Mail or Newsgroup account. This Wizard will collect the information necessary to set up a Mail or Newsgroup account. If you do not know the information requested, please contact your System Administrator or Internet Service Provider.' Also on that dialog, is a radio button group: (*) Email account ( ) RSS News & Blogs ( ) Unix Mailspool (Movemail) ( ) Gmail ( ) Newsgroup account. Looking at the Account Wizard with accerciser shows that that first radio button has a focused state. Normally when a dialog appears, there should be some kind of focus event for the object that has focus. For example, here's the events that occur when the Spell dialog appear in gedit: OBJECT EVENT: window:activate detail=(0,0) app.name='gedit' name='Check Spelling' role='frame' state='active enabled modal sensitive showing visible' relations='' SPEECH OUTPUT: 'Check Spelling frame' OBJECT EVENT: object:state-changed:focused detail=(1,0) app.name='gedit' name='None' role='text' state='editable enabled focusable focused sensitive showing single line visible' relations='labelled by' SPEECH OUTPUT: 'Misspelled word: quiiiick Context is the quiiiick brown fox' So this suggests to me, that this is a Thunderbird bug. It should be sending us a "focus:" event for that radio button. Joanie, are there known problems in this area?
> Normally when a dialog appears, there should be some kind of focus > event for the object that has focus. [...] > So this suggests to me, that this is a Thunderbird bug. It should be > sending us a "focus:" event for that radio button. > > Joanie, are there known problems in this area? Yessir. I filed some bugs on that front. The question is, what happened to them? I'll poke around Mozilla's bugzilla and see what I can find out. Thanks for looking into this!
Rich, looks to me like the fix associated with this bug got unfixed: https://bugzilla.mozilla.org/show_bug.cgi?id=388187 Do you concur? If so, I wonder if it's across the board (i.e. in all of the test cases listed in that Mozilla bug) or just in this one particular dialog?
Yes indeed. That bug looks identical to the one I've just been looking at. According to: https://bugzilla.mozilla.org/show_bug.cgi?id=388187#c23 there was a fix checked in on 6th October 2007. If so, then it doesn't seem to be working now. I'm testing against: $ ./thunderbird --version Thunderbird 3.0a2pre, Copyright (c) 1998-2008 mozilla.org I don't know if it's across the board. Can you think of another example I could test?
Yes indeed. That bug looks identical to the one I've just been looking at. According to: https://bugzilla.mozilla.org/show_bug.cgi?id=388187#c23 there was a fix checked in on 6th October 2007. If so, then it doesn't seem to be working now. At least for the accounts wizard. I'm testing against: $ ./thunderbird --version Thunderbird 3.0a2pre, Copyright (c) 1998-2008 mozilla.org I don't know if it's across the board. For the other two examples you reported in the earlier bug, I now get the following: b. Import wizard in address book OBJECT EVENT: focus: detail=(0,0) app.name='Thunderbird' name='Import everything' role='radio button' state='checked enabled focused horizontal opaque selectable selected sensitive showing visible' relations='' BRAILLE LINE: 'Thunderbird Application Import Frame ScrollPane or select the type of material to import: Panel &=y Import everything RadioButton' VISIBLE: '&=y Import everything RadioButto', cursor=1 SPEECH OUTPUT: 'or select the type of material to import: panel' SPEECH OUTPUT: 'Import everything selected radio button' That seems reasonable. c. Page setup dialog OBJECT EVENT: focus: detail=(0,0) app.name='Thunderbird' name='<b>Any Printer</b> For portable documents' role='combo box' state='enabled focused sensitive showing visible' relations='labelled by' BRAILLE LINE: 'Page Setup Dialog Format for: Combo' VISIBLE: ' Combo', cursor=1 SPEECH OUTPUT: 'Format for: combo box' For this case, it's not speaking the current combo box value, but that looks like it's a separate bug.
Ignore comment #5. I pressed Send before I was ready.
Heh. I was just replying to it when I got the mid-air collision for comment #6. :-) In the page setup dialog, the combo box didn't used to be there. Before a radio button started out with focus. As for the combo box value, I have a bug with "testing required" somewhere.... bug 536455.... Hopefully that patch will fix the combo box in question as well. And if it doesn't.... well.... combo boxes suck and no one should use them. ;-) Anyhoo, if it's just in the one (account) wizard, perhaps it's worth filing a new bug against Thunderbird, as way back when we were getting jack for focus events....
Hi, Sorry to be AWOL at the moment--I've got some work I'm trying to get finished today. However, I just wanted to let you know that the bug you are following is not the one I reported. The problem I reported is related to starting Thunderbird after everything is configured. As of yesterday, after starting Thunderbird, focus is in the "Quick Search" edit box, yet Orca does not indicate this fact. At other times, focus has been in the message list (where it should be), and the selected message was not spoken. Once I get this manuscript off my desk and on to someone else's (hopefully tonight :-), I'll produce a debug.out to demonstrate what I reported. Sorry for the wait.
Dave thanks so much for the clarification! You know, when I launch Thunderbird, focus is not in the quick search text entry. In fact it's nowhere. The frame seems to be the only thing that has focus, and that is what Orca speaks to me. In order to type a search, I have to press Tab once. Are you definitely in that entry? If so, a debug.out would be great!
Sorry to be spammy, but just for additional clarification: What I described in comment #10 is true whether Orca is running or not. In other words, we're not changing what has (or doesn't have) focus. It seems to be a design decision on the part of the Thunderbird developers.
Joanie, you are catching me not being as precise in my testing as I should be... ;-) What I know is this... if I hit Shift-Tab after the program starts, I end up in the message list. So, I assumed that I was in the quick search dialog box. (I should note that hitting Tab doesn't get me anywhere, if memory serves me correctly). I'll try to get the debug.out this weekend.
Thanks David. Changing the status to NEEDINFO because we can't progress this bug without it. As an aside, I don't think you should find any issues when you press Tab in the environment we're talking about in this bug, but your comment prompted me about something I was meaning to mention. There's a Gtk quirk in which pressing Tab in an entry doesn't move you out of that entry (like in the Save As dialog for your combo box bug). In that case you don't have to press Shift+Tab repeatedly, you should be able to press Control Tab instead of Tab to move forward. Anyhoo, thanks again for all your help!
Created attachment 113181 [details] debug log for two Thunderbird launches Joanie, I think you are correct. Focus seems to be only on the frame--with a default position in the tab order assigned (whether by design, who knows). In this file, I started Thunderbird twice. In the first, I pressed Shift-Tab to get to the message list. In the second start, I pressed Tab to get to the Quick Search edit box. If you type text before using the tab order to give something focus, there is no effect until you type one of their single letter hot-keys. I did edit this debug.out to remove my passwords--you have a nice key logger built in to Orca. ;-) For the record, I'm using svn trunk rev 3993 adn the latest nightly for Thunderbird.
Sorry, just changing the status of the bug.
Thanks David. So then here's the question: If focus really is on the frame -- for all users; not just Orca users -- and Orca is correctly indicating that condition, what is the bug? If the bug is that focus should be somewhere else, an RFE could certainly be filed against Mozilla -- after all, it's not the place of a screen reader to change focus. I'm hesitant to file such an RFE though, because who is to say where focus should be? You might want it in the list of mail folders, Rich might want it in the list of messages, and I might want it in the search entry. Regardless, and getting back to this bug, unless I'm missing something, my temptation would be to close it out as NOTABUG. In the process of investigating the problem we thought was the issue, Rich discovered a bug: The focused radio button in the Account wizard dialog isn't giving us initial focus events. I filed a Mozilla bug here: https://bugzilla.mozilla.org/show_bug.cgi?id=441233 We could make this bug a blocking/tracking bug for that issue; or we could open a new bug for that issue. I'll leave that up to Rich since this is his bug. :-)
Hi, Joanie, I agree, this is not an Orca problem at the moment. I have a few bugs to file with Mozilla, so I will add an RFE for focus to be put in the message list (the behavior of the Windows version of Thunderbird). As it stands, I think it will be confusing to a new user to not have anything focused--knowing that you need to use the Tab key to get something focused is a poor initial state in my opinion. I would suggest that this one be closed and the other problem get its own bug. I'm not sure about Bugzilla, but I would guess that I could reopen this bug if the need arose. There have been times in the past when the message list did have focus, and nothing was spoken at that time. So, I would prefer to keep this bug available if this problem turns out to be real. My thanks to Rich and you for your help.
Sounds like a plan. I just opened bug 539682 for the radio button issue. I'll leave it to Rich to close this one out as he did all the work. :-)
Okay. Closing as NOTABUG. Thanks Joanie and David.