GNOME Bugzilla – Bug 633186
Orca looses focus on message contents when using thunderbird with open message in new window
Last modified: 2011-01-22 14:46:26 UTC
If using thunderbird (3.1.5) with show messages in new window, when you open the message orca looses focus on the message contents meaning you must do something to make it regain focus (eg. click the routing key on the Braille display or alt+tab away and back). From what I observe it appears there may be an additional window focus event taking focus. Steps to reproduce: 1. Set thunderbird to show messages in a new window. 2. While orca is running select a message in thunderbird and press enter to open it. Expected: You will be placed on the message contents and could cursor through. If orca is set to read automatically then the message will be read. Actual: Orca announces the new window, speaks the first line of the message and then speaks the window title again. This does not always happen but for me it happens almost every time (I think the occasions its worked correctly I could count on the fingers of one hand).
Created attachment 173255 [details] A debug showing the additional event which seems to take focus away from the message contents. This debug shows the situation occuring. I simply started orca, alt+tab to thunderbird, tab into the inbox and press enter to open a message. I then press orca+q to quit. This debug shows the event which seems to take focus away from the message area, so I am not sure whether this might be a thunderbird issue or whether orca can work around this.
If orca is set to read automatically then the message will be read and I can cursor through the message. Sometimes if I alt+tab to other application and alt+tab back to the message, I can not cursor through.
I have done some testing of different versions of thunderbird to see where this bug appeared. It seems to start in thunderbird 3.1, thunderbird 3.0.9 seems to be the last version where orca doesn't show this bug. If we feel this is a bug in thunderbird I can try and track down what date the bug was introduced, but before I start spending time on that I would like it if someone could suggest whether that is a good way to go or whether its something which needs correcting in orca.
I have also observed this problem for some time. I don't remember when exactly this began. I have just today changed to have messages open in a tab instead and this problem does not happen then. However, I have lost focus occasionally when switching to another program and came back. I would usually just reply to a message and then close it without any editting and then I regained focus. I also ran into some strange focus issues today but couldn't put my finger on it exactly so will have to watch this more closely in the future and start doing some Accerciser tracking or something.
I don't know how much this will help but I notice the following: * If the message starts with a link (eg. the bugzilla emails for changes to bugs) then orca keeps focus on the message contents and this bug does not show itself. * This bug also occurs if opening the message to view source code (IE. pressing ctrl+u on a message in the message list). The thing about the link seems most interesting to me, what is different about when the cursor is on a link and when it isn't?
Created attachment 175318 [details] [review] A proposed fix This patch I think should fix the issue. It fixes the issue by ignoring window:activated events from the current window. I really feel this should have testing as it feels quite an assumption to say that if a window is already the actigve window then further window:activated events from it have no meaning. Initial testing on my system seems to suggest it is fine but you cannot have enough testing.
(In reply to comment #6) > Created an attachment (id=175318) [details] [review] > A proposed fix > > This patch I think should fix the issue. It fixes the issue by ignoring > window:activated events from the current window. I really feel this should have > testing as it feels quite an assumption to say that if a window is already the > actigve window then further window:activated events from it have no meaning. > Initial testing on my system seems to suggest it is fine but you cannot have > enough testing. I forgot to say, this fixes the problem in default.py, so it applies to all applications, it could be moved to the gecko script (I think I have recently observed firefox showing this bug). If it should be kept global like this, then is it in the right place to ignore these events, could they be ignored even more in the core of orca?
I've not looked at the bug, but hacking around a Gecko issue in default.py where it can impact *all* applications seems like a less-than-ideal situation. *If* we hack around this, we'll hack around it so that it only impacts Gecko apps. But as I just said on list, I'd much prefer bugs in other people's apps and toolkits be fixed there.
Review of attachment 175318 [details] [review]: C&P from my response on the list: Hey Michael. I do have one question before I go and do that, could there ever be a > meaning to the active window giving the window:activated event more than > once? Why I ask this is, might it be worth adding my fix to orca anyway > should the mozilla bug be hard to track down? I'll give it some thought. But in the meantime, I have a question for you: Can you guarantee me (and the full Orca community) that there will *never* be such a meaning? Because if you cannot, I would be very hesitant to put something in the method that handles pretty much all window:activate events and say "nah, we'll ignore some of these based on a simple equality check." Like I said, *if* we wind up hacking around this in Orca, we will limit it (i.e. to the Thunderbird script; not default.py). And we will add more heuristics to ensure we don't accidentally ignore something we shouldn't. And to be honest, we'd probably put it somewhere else like locusOfFocusChanged. But, like I also said, they have a really awesome engineer doing work directly in support of our community's needs. Please file a bug in Mozilla's bugzilla and let's see how that plays out. Thanks! --joanie
OK, there is some good news and some bad news. The good news is that this bug goes away with gecko 2.0 products, so if you upgrade to the 3.3 builds of thunderbird (currently in alpha) you won't have the issue. Now the bad news, there is a bit of it. This bug actually is more general than just thunderbird, it affects firefox 3.6.x as well and can give very odd behaviour (IE. if I have firefox already open and launch another instance then I can read the page while gnome-terminal still has focus). Supposedly firefox 4.0 doesn't have this problem as it uses gecko 2.0. Now there is more bad news, I did file a bug with mozilla about this, see https://bugzilla.mozilla.org/show_bug.cgi?id=615064 for more details. The short of it is that gecko 1.9.2 is towards the end of its development and so only critical and crashing bugs are being fixed with it. The feeling seems to be that this would be unlikely to be accepted into gecko 1.9.2. I feel if a fix could be found then may be it should be included as this will affect users (those not wanting to use testing/development builds) for some time as thunderbird 3.3 is only on a1. If you feel strongly then may be add your comments. One final question, what direction should this bug report go?
Since there is a work-around for this problem currently by not opening the message in separate window, and given the end of life situation for gecko 1.92, I'm enclined to suggest no changes to Orca because that would probably introduce more hacks to hender performance where it already suffers. I'm presently using Firefox 4.0 with few problems but haven't tried late builds of Thunderbird yet. I do have some problems with html rendoring in FF 4.0 but that's for another conversation. I would like to note that in some other situations, some a11y issues were resolved by using bleeding edge versions of software. Open Office comes to mind here. I could not use the navigator in prod versions of OOo but the dev build improved that situation emensely.
Since this issue is 1 fixed in nightly builds for thunderbird 3.3 and there is a work around for broken versions that is pretty trivial I'm calling this closed. If someone can reproduce this in a nightly build please reopen.