GNOME Bugzilla – Bug 541018
Mail messages not automatically read when opened in Thunderbird
Last modified: 2009-03-10 00:05:06 UTC
Please describe the problem: With "Automatically start speaking a page when it is first loaded" enabled, Orca does not read a message aloud when it is first opened. Only the first line of the message is read--the default behavior when automatic reading is disabled. Steps to reproduce: 1. Start Orca. 2. Start Thunderbird. 3. Open Application specific preferences for Thunderbird (Orca modifier-control-space bar), move to the Thunderbird tab, and enable "Automatically start speaking a page when it is first loaded." 4. Activate OK button. 5. In Thunderbird message list, open a message. Actual results: The first line of the message is read aloud. Expected results: The entire message should be read aloud. Does this happen every time? Yes. Other information:
The variable that deals with whether the page is spoken or not when it's first loaded is .../Gecko/script_settings.sayAllOnLoad The code that uses that is in the onStateChanged() method in Gecko/script.py. The problem is that the onStateChanged() method in Thunderbird/script.py just bypasses the parent class method in Gecko/script.py and goes straight to the equivalent in default.py. One possible fix is to replicate all the code for this condition in the onStateChanged() method in Thunderbird/script.py. Another approach is to call the Gecko/script.py onStateChanged() instead of going to the default.py one. (i.e. just remove the onStateChanged() method in Thunderbird/script.py entirely). Joanie, as you are *way* more familiar with the Gecko implementation then I am, I'm passing this over to you, to decide what the best solution to this is.
As an experiment, I tried the complete removal approach which caused the the Gecko onStateChanged() to kick in. Two things occurred: 1. We spoke "loading". We don't want to speak loading messages according to Mike via IRC. Right now those messages are at least sometimes cut off by a speech.stop(), but that might change as the result of another bug I'm working on. 2. In the block of code that begins with: if finishedLoading: sometimes obj == None and we return. This wasn't the case when deleting open messages, but did seem to be the case when pressing Return from the message list. So additional work will be needed to figure out why there's no obj. It could be the result of the customized getDocumentFrame() in Thunderbird which was needed as part of the bug fix to not impact the cursor position when editing a message (see bug 51161). If so, I'm interested in knowing why we're not always correctly identifying the document frame. Or it could be something else, which I'd also be interested in knowing. :-) So.... Jury is still out until I know why obj is sometimes None. If that's a bug that is easily fixable, then we could potentially remove the custom onStateChanged() and add a check to the one in Gecko to prevent us from speaking the loading messages. As a related aside, Mike just said in IRC that the default value of sayAllOnLoad should be False in the Thunderbird script, but True for Firefox.
Thanks Joanie. I'll put my name on this one, and continue investigating it.
Created attachment 113867 [details] Orca debug log generated whilst testing this problem. > 2. In the block of code that begins with: > > if finishedLoading: > > sometimes obj == None and we return. This wasn't the case when deleting open > messages, but did seem to be the case when pressing Return from the message > list. So additional work will be needed to figure out why there's no obj. If you user presses Return from a message in the message header list, to open up a new window with that message displayed in it, then when we get the second "object:state-changed:busy" event (see line 658): OBJECT EVENT: object:state-changed:busy detail=(0,0) app.name='Thunderbird' name='[Bug 537063] [testing required] State of "show system tray icon" combo box in Pidgin preferences not shown correctly' role='document frame' state='enabled focusable focused horizontal opaque sensitive showing visible' relations='node child of' then the "if finishedLoading:" section of the onStateChanged() method in Gecko/script.py calls: [obj, characterOffset] = self.getCaretContext() This in turn calls getDocumentFrame(), and picks up the one in Thunderbird/script.py. At this point, orca_state.locusOfFocus is: app.name='Thunderbird' name='None' role='table cell' state='enabled focusable focused opaque selectable selected sensitive showing vertical visible' relations='node child of' (i.e. the table cell back in the message header list), so getDocumentFrame() returns None. We can obviously get the document frame from event.source, but I'm still trying to work out the best way of patching this into the existing Gecko/script.py code, so doing this is for Thunderbird only.
Created attachment 113890 [details] [review] revision 1 Yet another Rich and Joanie tag-team effort. :-) Please test. Note that the new default setting for doing a SayAll upon load is False for Thunderbird, but True in Firefox. Therefore to test this, first change the setting in the Orca Preferences for Thunderbird dialog.
Forgot to mention, because a new file was added, you will need to do a full install (starting with the autogen). To remove the patch and go back to normal, you should sudo make uninstall before reversing the patch or installing a fresh trunk. Also note that because there is now a Thunderbird-specific setting for the sayAll, you'll want to remove the following line from your ~/.orca/app-settings/Thunderbird.py after testing: orca.scripts.apps.Thunderbird.script_settings.sayAllOnLoad = True
With reading automatically enabled, this patch appears to be working well. It works well both when opening a message from the message list as well as after deleting a message with message view open--the next message is read automatically. However, with reading automatically disabled, I am getting extraneous information read. Sometimes this is header information being read before the first line of the message is read. At other times, it is information from within the message, not read in order. I'll attach a debug output showing this behavior. Also, if I delete a message while in the messsage view, then press escape to close the message view, focus has moved approximately 30 entries up in the message list (sorted ascending). I'll reverse the patch and see if this behavior persists.
Created attachment 113923 [details] debug output showing extraneous information to be read I opened a message from the message list, read it (or started), then hit the delete key while still in the message view.the next message is opened, the first line is read, then stray information from within the message is read. Read automatically is disabled with patch applied to svn trunk rev 4021.
Sorry, both problems exist, but they are not related to the patch. I reversed the patch, and the extraneous speech continued. To be sure, I moved back to svn trunk rev 4017 and tested again. The extraneous speech remains. Also, the jump up approximately 30 messages in the list also continues with rev 4017. If anyone can confirm either of these behaviors, I'll file a bug for them tomorrow. So, I would have to say that the patch is working well. Thanks.
Dave, I can confirm the jump up the message list without Orca running. It's a Thunderbird behavior. When you delete a message that is open, focus in the list jumps to the top of the list. When you then press Escape and land back in the list, you're at the top. Orca is simply reporting where you are.
Hi, Joanie, This isn't jomping to the top of the list. My mail box is a little out of control at the moment--between 55 and 60 messages. When I delete a message with message view open, read the next message, then close message view, the focus in the message list jumps from the 57th message to the 29th message. It doesn't appear to be perfectly consistent, but the jump is always roughly that amount. And, if I deleted the 57th message, it was not the last message in the message list--the condition for jumping to the top of the message list. I can email you a debug log if you want to take a look... you have so little else to do... ;-)
Heh. But I just love reading debug logs. ;-) Sadly I don't think a debug log would help in this case. I tend to filter messages to the point that I don't have that many in my inbox, but I an add some more and try to make the jump not be the top. Regardless, when you delete an open message, Thunderbird (and not Orca) changes the selected item in the message list.
Sorry, I should have made it clear that this problem would be filed with Mozilla (I have about 3 other bugs to file there right now...). Since you love reading debug logs, I'm glad I could provide you with one more to read this morning... ;-) If you think I should just file a new bug for the extraneous chatter described above, I'll do that and repost the debug log to that bug report.
Filing a new bug and reattaching the output would be awesome. Thanks in advance! Patch committed to trunk. Moving to pending. Reassigning to me in case it turns out I just broke somethin' ;-) Rich, thanks for your help!
SayAll seems to be working and I don't believe this fix broke anything else. ;-) Therefore, closing as FIXED.