GNOME Bugzilla – Bug 533042
Orca should be less verbose when reading autocompletes in Thunderbird
Last modified: 2009-03-10 00:05:16 UTC
Currently in thunderbird in the to field when autocomplete information becomes available we speak it with every key press. What we should actually do is only speak the autocomplete once for each change. For example If I type "da" and Dan appears I should not hear "dan" again if I type "n". However if the next character I typed after the "a" was a "v" I would hear "david" if that appeared. Joanie and I talked about this on the phone earlier I'm just putting this hear to keep a record.
Created attachment 111703 [details] [review] revision 1 Mike please give this one a shot. Thanks! (Already pylinted; no applicable regression tests to run as the changes are all within the tbird script.)
David! <hopeful smile> I hope you don't mind my adding you to the CC list of this bug, but you clearly have an interest in getting more compelling Thunderbird support in place, and I could use your help on this one. Here is the situation: Right now, when you start typing an address in the To (or CC or BCC) field and Thunderbird recognizes that address, it autocompletes it. As a result, Orca speaks the new address to let the user know that this has taken place. If you continue to type at that point, you nuke the completed text (because it was selected), Thunderbird recognizes the address and (voila!) autocompletes it for you. Again. And thus we speak it. Again. Rinse and repeat. This strikes us as being a little too chatty. So I've got this marvelous patch in comment #1 that does exactly what Mike requested in his opening comment to this bug. But it only seems to work on my system; not Mike's. <smile> We don't yet know why/what the magical difference is. So.... Would you mind giving the patch a try and letting us know if it fixes it for you or not? Based on your findings, combined with what we do know, we can hopefully progress towards a reliable fix. Thanks very much in advance!
I tried the patch and I'm afraid that it doesn't help for y system. As each character is typed, the completion suggestion is repeated. Would you like a debug.out? Just for more info, I'm running Ubuntu Gutsy, Orca svn trunk, and latest nightly build of Thunderbird.
I would positively love a debug.out David. Thank you!! Something just occurred to me: David -- and Mike -- are you using the latest version of AT-SPI? What the patch is looking at is the event's any_data. If that's not present or persisting or .... something else.... it would explain why the patch is failing.
I am using at-spi, rev 1014, which appears to be the latest. However, as I have posted to the mailing many months ago, I get a bunch of warnings when I build at-spi. I look them over each time, and generally they are the same, with some new ones appearing and some old ones disappearing. Would anyone like to look at them?
Created attachment 111779 [details] debug output while testing patch I think you will want to look around about line 713. One additional chatty thing about these completions is that, when you have the correct completion and press tab to move to the subject edit box, you hear the addressee's name and email address once again. Can this last repetition also be eliminated? (I know, I don't ask for much... ;-)
David, you're awesome. I do appreciate it. And no, you don't ask for much, plus you help us considerably when it comes to tracking these things down, so yeah, I suspect we can do something about that last repetition. ;-) But first.... I'm noticing a couple of things about your output. Here's a sample event: vvvvv PROCESS OBJECT EVENT object:text-changed:insert:system vvvvv OBJECT EVENT: object:text-changed:insert:system detail=(0,44) app.name='Thunderbird' name='To:' role='entry' state='editable enabled focusable focused horizontal opaque sensitive showing single line visible supports autocompletion' relations='' Thunderbird.py: onTextInserted: utterances='['Da >> "David E. Price" <deprice@cs.utah.edu>']' SPEECH OUTPUT: 'Da >> "David E. Price" <deprice@cs.utah.edu>' ^^^^^ PROCESS OBJECT EVENT object:text-changed:insert:system ^^^^^ So what I'm seeing is this: 1. We're getting the event I'm looking for (yea!) 2. And sure enough, we're speaking it when we shouldn't be (boo!) But here's the kicker.... The change I made in my patch to handle the event in question no longer uses speakUtterances(). And when I removed that code, I also took out the debugging code that printed out what utterances were to be spoken. And yet, looking at your debug.out, I see examples of the original/removed statement, for instance: Thunderbird.py: onTextInserted: utterances='['Da >> "David E. Price" <deprice@cs.utah.edu>']' In your comment you indicate that this is debug output "while testing the patch." I hate to ask this, but is there any chance you attached the wrong debug.out? The other thing I'm noticing is in the focus event for the To field (ends at around line 960). I see that we're speaking a couple of things: SPEECH OUTPUT: 'To: autocomplete' SPEECH OUTPUT: 'To: text ' The fact that we're speaking the autocomplete role as well as the text role surprises me, because in mid April, as part of some chattiness removal in bug 512103, the autocomplete role came out of the context when focus was given to an entry whose parent is an autocomplete. So old-school Orca said things like "location autocomplete location text" and "search using google autocomplete search using google text." It doesn't do that any more. Orca should now just say "location text" and "search using google text." As part of your testing, are you maintaining both a stable/gnome-2-22 Orca and the unstable/trunk/gnome-2-23 on the same machine? And, if so, any chance that you didn't re-install the trunk version for your latest test? I've done that before.... Thanks again!
I keep two versions of Orca svn trunk, which I alternate between. This gives me one that I know is stable enough to work with, and a second that I am testing. The only branch I have is 2.20, rev 3612. However, I had to look up the name of the directory, so it is unlikely I was accidentally making new versions in this directory. :-) When I type orca --version, I get the following: Orca 2.23.3pre This is the first time I've ever generated a debug.out, so I don't see how it isn't the one I generated. Also, the time stamp is appropriate. Tonight or this weekend, I'll check out a clean copy of trunk, patch it, build it, and then generate a new debug.out (with a unique name ;-). I'll post it when it is done.
Thanks again David. The other thing I noticed after I made my comment -- something which is easier for you to spot when looking at your debug.out output -- is the script name. Recently we had a major refactor and scripts are in places they were not before. When testing this patch and looking at the results, you should find a window:activate event in your debug.out for Thunderbird. When the window gets activated Orca looks for the Thunderbird script and you should get some lines that look like this: Looking for script at orca-scripts.Thunderbird.py... ...could not find orca-scripts.Thunderbird.py Looking for script at scripts.Thunderbird.py... ...could not find scripts.Thunderbird.py Looking for script at scripts.apps.Thunderbird.py... ...found scripts.apps.Thunderbird.py Thunderbird.SpeechGenerator: __init__ NEW SCRIPT: Thunderbird (module=orca.scripts.apps.Thunderbird.script) Orca is controlling the caret. What's important there is the NEW SCRIPT line. Comparing what you should get (above) to what you have in your output (below): Looking for script at orca-scripts.Thunderbird.py... ...could not find orca-scripts.Thunderbird.py Looking for script at scripts.Thunderbird.py... ...found scripts.Thunderbird.py Thunderbird.SpeechGenerator: __init__ NEW SCRIPT: Thunderbird (module=orca.scripts.Thunderbird) That, combined with what you're getting for the version info, suggests that you shure 'nuff are using trunk and probably patched Thunderbird just fine :-), but that Orca found the old unpatched Thunderbird script instead. Therefore, as part of the "cleaning out" process, please be sure you remove the old stuff lingering in your /usr/lib/python2.5/site-packages/orca directory. Thanks!
OK. Just to be sure, what you are saying is that I should completely clean out that directory before my next build, correct? As an aside, Rich's message on May 28, subject Orca flag day, talking about using a clean svn check out, didn't mention cleaning out this directory. Did I miss a message telling me to clean out this directory? It sounds like everyone using trunk should do this. It might be worth a message to the mailing list... otherwise,this will be a constant problem.
I would clean it out. And I would clean it out carefully. Just yesterday I was trying to get to the bottom of something while also on the phone and "over cleaned" accidentally. If you delete your entire site-packages directory, you will be sorry. Trust me. <grin> Just get rid of the "Orca" directory that happens to be inside of site-packages. And of course then reinstall Orca. As for Rich's message: The files you need to remove are remnants from the script refactor from around the start of this month. Rich's change, and hence his flag day message, were something else I'm afraid.
Created attachment 111852 [details] debug output after cleaning out old files I cleaned out the directory (mine was under /usr/local), updated Orca trunk (rev 3944), patched it, built and isntalled it. Now Orca is finding the correct script, but Orca does not speak in Thunderbird. There is a trace in the debug file.
I think we're getting closer. :-) The tracebacks say this: Traceback (most recent call last):
+ Trace 199276
self.loadAppSettings(orca_state.activeScript)
__import__(name, globals(), locals(), [''])
orca.Gecko.controlCaretNavigation = True
Instead of orca.Gecko, I would expect to see orca.scripts.toolkits.Gecko.script_settings More refactor stuff. Primarily the original (early-May) refactor slightly tweaked by Rich's (and alluded to in the "flag day" message). Anyhoo... In your ~/.orca directory, you have an app-settings directory. Thunderbird.py and Thunderbird.pyc need to go at the very least. If you have similar files for Firefox/Mozilla, Pidgin, and StarOffice you might find similar issues and should delete those app-settings files as well. Thanks again!
Created attachment 111865 [details] debug output showing no in mail box tree and message list I'm now not receiving any speech support in the main Thunderbird window--mail box list or message list. I don't believe that I've updated to the latest nightly, which Mike Reiser reported on the mailing list as possibly having this problem. Attachment for problem in this bug to follow.
Created attachment 111866 [details] Debug output showing bug still exists I'm afraid that Orca is still repeating the auto-complete after each letter is type.
(In reply to comment #14) > I'm now not receiving any speech support in the main Thunderbird window--mail > box list or message list. I don't believe that I've updated to the latest > nightly, which Mike Reiser reported on the mailing list as possibly having this > problem. Attachment for problem in this bug to follow. > Thanks David. Looking at the debug.out, it seems like we're not getting events (e.g. focus events letting us know that we're in a new location). I've got a couple of errands to run today, but I'll work on this when I get back. Also, based on your comments, I wrote up a more detailed "flag day" message. Hopefully it clarifies things, but if there's anything I neglected to say in that message, please reply to the list with the missing details. 'Cause you're right, this will otherwise be a constant problem.
Joanie, as I was sending out some email messages tonight, I noticed a behavior that may be of interest to you. When I am sending a message to an address with a unique first letter (by that I mean that the address is the only one starting with that letter), the autocompletes are not spoken after the initial autocomplete is spoken. So, in these cases, things are working perfectly. However, if multiple addresses start with the same first letter, the autocomplete is announced after each letter is typed. If you want a new debug.out showing this behavior, let me know. Thanks.
I'm still seeing the same behavior as David.
Based upon Mike's comments, marking this as needs-work. :-( We'll get there. :-)
Created attachment 113292 [details] [review] revision 1 with debugging lines added I'm sorry guys, I'm really at a loss. I've tried it on my hardy box and I've tried it on my intrepid box. I've tried it with multiple matching entries in my addressbook and I've tried it with only one matching entry. My debug.out looks like David's with one exception: In mine, we're not speaking the autocomplete text (i.e. the patch fixes the bug for me); in David's we are. Therefore, I need more of a hint. The attached patch is revision 1 with a number of debugging lines added to spit out the info I care about in your debug.out file. Please apply this patch and capture a full debug.out. Thanks!
Hmmmm it's now working for me on a stock up to date hardy. If it works for David I'd say check it in without the defug stuff.
Created attachment 113297 [details] debug output after debug patch I'm using Gutsy and the problem still exists. Let me know if you need more info.
Aha! Thanks Dave. I'm guessing that the entry you have for you in your addressbook is missing a first name or a last name or something. If I start typing my name, I get something along the lines of: I type a j; tbird fills out Joanmarie Diggs <joanmarie.diggs@gmail.com> I type an o; tbird fills out Joanmarie Diggs <joanmarie.diggs@gmail.com> I type an a; tbird fills out Joanmarie Diggs <joanmarie.diggs@gmail.com> And so on and so forth. i.e. the autocomplete info isn't changing. What I'm seeing in your output is: You type a D; tbird fills out D >> "David E. Price" <deprice@cs.utah.edu> You type an a; tbird fills out Da >> "David E. Price" <deprice@cs.utah.edu> You type a v; tbird fills out Dav >> "David E. Price" <deprice@cs.utah.edu> i.e. the autocomplete info is different each time. Dunno why that is, but I can replicate it by skipping my first name and just typing my lastname. Lemme come up with a new patch that checks for this condition and just compares string endings.
Created attachment 113299 [details] [review] revision 2 This checks for the condition Dave presented as well. Please test. Thanks!
It works! :-) Just to give you some background... I believe all of the entries in my address book have been collected by Thunderbird--I don't remember having added any entries manually. Of course, each time I send a message, the outgoing address(es) are added to the address book. When I pull up the address book dialog box, I only have a few entries available in the Tab order--two are relevant: the name field and the address field. In the name field for my usual email address is: David E. Price <deprice@cs.utah.edu>. In the address field is just the email address: deprice@cs.utah.edu. However, when I use flat review (a happy situation, since flat review has problems in many other parts of Thunderbird--I'll file bug reports when I get the time), I find a "card" for this entry. In this "card" the name field contains: David E. Price. the address field contains: deprice@cs.utah.edu. I don't know if these entries are the same ones I can tab through, but the name field is different when using flat review mode. I pass it along for whatever it is worth. One other aspect if you want to do any additional sleuthing... the next entry is for the other account that Thunderbird is configured to read. In both the name and address fields are the same entries: David.Price@utah.edu. Maybe a source of the confusion, who knows. One final note... when I was testing this and found that it only occurred if there were multiple names starting with the same letter, I tried many different names, all with the same behavior. I guess I'm putting this down for academic reasons (or, in case this patch fails for someone else, unlikely as that may be ;-). As far as I am concerned, it is working well and can be checked in. Thanks for all the effort!
> It works! :-) Wooo hooo!!! If there were a way to ftp champagne (or the celebratory beverage of your choice) it would be on its way. :-) > I guess I'm putting this down for academic reasons (or, in case this patch > fails for someone else, unlikely as that may be ;-). I appreciate your putting it all down. It can be hard to get to the bottom of these things. I hardly consider the details academic. > it is working well and can be checked in. Done! > Thanks for all the effort! And thank you for yours! Moving to pending so that it gets some more testing before we conclude that it's really a done deal.