GNOME Bugzilla – Bug 490317
Orca echoes the first letter of each new line when composing a message in Evolution
Last modified: 2008-07-22 19:33:18 UTC
Steps to reproduce: 1. Set Orca's key echo to words 2. Launch Evolution and press Control+N to compose a new message 3. Tab to the body of the message 4. Type a few words, press Return. Rinse and repeat. Expected results: Orca would not echo the character typed at the start of each new line in the message. Actual results: Orca does echo the character typed at the start of each new line in the message. (Note, this is not a pyatspi regression. It's present in the gnome-2-20 branch as well.)
Created attachment 100894 [details] Orca debug ouput generate while running the test. The problem is caused because we are getting an extra (bogus?) "focus:" event when we type the first character in each new line in the Evolution compose message, message area. In more detail: When we Tab from the Subject: line into the message body, we get a "focus:" event (see line 723): OBJECT EVENT: focus: detail=(0,0) app.name='evolution' name='None' role='text' state='editable enabled focusable focused multi line sensitive showing visible' relations='' This ends up calling locusOfFocusChanged in the Evolution script and we speak "blank" (see line 762). When we then type the first character ("l") in that message area, we get another (bogus?) "focus:" event (see line 777): OBJECT EVENT: focus: detail=(0,0) app.name='evolution' name='None' role='text' state='editable enabled focusable focused multi line sensitive showing visible' relations='' Again, this results in calling locusOfFocusChanged in the Evolution script and we speak "l" (see line 824). For the rest of the characters that we type on that line, we are just getting an "object:text-changed:insert" event (for example, see line 873): OBJECT EVENT: object:text-changed:insert detail=(1,1) app.name='evolution' name='None' role='text' state='editable enabled focusable focused multi line sensitive showing visible' relations='' and this is going through the onTextInserted() method in default.py where there is a proper check for whether we just have echo by word. When we enter Return at the end of that first line, we get a "focus:" event (see line 1124): OBJECT EVENT: focus: detail=(0,0) app.name='evolution' name='None' role='text' state='editable enabled focusable focused multi line sensitive showing visible' relations='' This again ends up calling locusOfFocusChanged in the Evolution script and we again speak "blank" (see line 762). Then we type in the first character on the second line ("n"), and we get another (bogus?) "focus:" event (see line 1220): OBJECT EVENT: focus: detail=(0,0) app.name='evolution' name='None' role='text' state='editable enabled focusable focused multi line sensitive showing visible' relations='' Again, this results in calling locusOfFocusChanged in the Evolution script and we speak "n" (see line 1267). and so on... This looks to me like YAEB, and I should file it. Will do you agree? I'm not sure if it is possible to work around in the Evolution script.
> The problem is caused because we are getting an extra (bogus?) > "focus:" event when we type the first character in each new line > in the Evolution compose message, message area. If the event source is the same object, then orca.setLocusOfFocus should detect this and not pass things on: if obj == orca_state.locusOfFocus: return Given the debug.out file you posted (thanks!), it seems as though this condition might be failing. So, I wonder if Evolution creating a whole new object or something. > This looks to me like YAEB, and I should file it. Will do you agree? It definitely looks bogus to me. The focus is not changing as far as I can tell. > I'm not sure if it is possible to work around in the Evolution script. Instead of the above snippet, you might try something like: if (obj == orca_state.locusOfFocus) \ or (orca_state.activeScript \ and orca_state.activeScript.isSameObject(orca_state.locusOfFocus, obj)): With this, maybe the script's isSameObject will detect the two are the same? return
> With this, maybe the script's isSameObject will detect the two are the same? Unfortunately it doesn't. It just falls out the bottom and returns False. I'll keep looking at it to see if something else turns off. Thanks.
That should be "up" not "off".
Will, do you want me to file an Evolution bug (see end of comment #1)?
While Evolution shouldn't be issuing redundant focus events for things that already have focus, I think we should be able to handle it gracefully. I'm still not clear on why isSameObject is not catching the redundancy. Is it possible that Evolution is deleting/recreating a new accessible object in these cases? One thing to do might be to try to look at the hash(event.source) values to see if they are changing. Another thing might be to see if there are any other intervening focus events.
> Is it possible that Evolution is deleting/recreating a new accessible > object in these cases? That would indeed appear to be the case. Joanie looked at this a bit yesterday and stated "looking at the events, as you observed the focus events are not for the same object." > Another thing might be to see if there are any other intervening focus > events. There are no intervening focus events. See my detailed analysis in comment #1. Joanie did comes up with a possible approach to try to solve this (thanks!), and I'll have a look at that in more detail on Monday.
I've opened bug #508170 against Evolution and am blocking this one against that. Having said that, there is work that needs to be done here. More to follow.
Created attachment 102426 [details] [review] Patch that starts to fixup some other related problems. The first problem found was that section 8) of the Evolution.py locusOfFocusChanged() method now has a different role hierarchy. I then had to modify section 1) as well to differentiate between the two. This part of the patch will definitely be needed, irrespective of whether we find a workaround for the reported problem, so that spell checking will work. The next thing was that just looking to see if the parents are the same and just returning, causes arrowing to another line in the compose window message area to not speak that line. So I've added in a check to see if the last user key input was an arrow key, and trigger off that. But that's really not a great solution as there are other keys (like Home and End) that need to be included. For the next version of the patch I'll add those two in as well. Still not a great solution though. The next problem (not fixed yet), is that when you do arrow to another line, it prefixes it with speaking "text". Section 1) of locusOfFocusChanged() fixes that for the message area of mailbox messages, so I can separate that code out into a new routine and call it in both places. I'll do that in the next version of the patch. Joanie, you had another suggestion for a potential fix involving the text caret offset. Could you add a comment to the bug giving more detail please? Thanks.
Created attachment 102435 [details] [review] Revision #1 This version of the patch is getting close to being usable. It adds the following: 1/ Also checks to see if the last input was from the keyboard. 2/ Adds "Home" and "End" to the list of navigation keys to check foo. 3/ Creates a new presentMessageLine() method that gets called from sections 1) and 8) of the locusOfFocusChanged() method in the Evolution.py script. Patch not committed yet until I've had feedback. Removing the "[blocking]" (sic) and adding a "[testing required]".
With your patch applied, speech and braille are not updated when you first move focus into the body from the subject. 1. Create a new message. 2. Tab to the subject. 3. Type "foo" 4. Tab to the body. Expected results: Orca would announce "text" (or something to let you know you're in a new field) and the braille display would be updated to reflect the new locus of focus. Actual results: Orca says nothing and the display continues to show the subject.
Joanie sent me another comment via email related to the proposed patch: 1. With word echo enabled, in the body of a message type "hello world" 2. Press Return Pre-patch, Orca would say "blank". Not ideal; saying "world" is expected. But at least we say *something*. Post-patch Orca says nothing at all when you press Return. I'll see if there is anything I can do to fix this (and the problem mentioned in comment #11) and still retain the not-speaking-the-first-character fix.
Created attachment 102600 [details] [review] Revision #3 Patch handles the two anomalies found by Joanie. It will now speak "blank" when Tabbing from the Subject line to the message area in the compose window (same as pre-patch). It will also now speak "blank" when hitting Return after typing in "hello world"<Return>, when just echo by word is enabled. I know it would be really nice to echo "world" in this case (like gedit), but I don't believe this is easily possible because of the nature of how Evolution constructs the components in the message area (i.e. it's not one single text area). Please test.
Works for me.
Thanks Joanie. Patch committed (slightly adjusted to get pylint score up to 10.00). Moving to "[pending]" state.