GNOME Bugzilla – Bug 523731
Pidgin events interfere with app-specific Prefs dialog
Last modified: 2008-04-29 19:41:46 UTC
Steps to reproduce: 1. Launch Calc (doesn't have to be Calc, but it's a good illustration) 2. Launch Pidgin and start a conversation with someone 3. Give focus to the Calc window and wait until the person has sent a message. 4. Leave focus in Calc, don't press any keys 5. Press Control+Insert+Space for the Orca Preferences for soffice Results: We do get an app-specific preferences dialog, and it's sorta for soffice: It does have the "Speak spread sheet cell coordinates" checkbox. But the dialog name is "Orca Preferences for pidgin" and the app-specific page tab label is "pidgin."
Created attachment 107754 [details] proof that I am not making this up :-)
Created attachment 107755 [details] debug.out
Looks like status changes will do it as well. This is easier than using two computers to talk to yourself. :-) (It would also explain why I was seeing this bug even when no one was talking to me). 1. Enable the braille monitor if it's not already enabled 2. Launch pidgin and some other app (like calc) 3. Give focus to the other app and wait until the braille monitor displays "cell" (which it seems to like to do during a status change). 4. Press Control+Insert+Space to get the app-specific Prefs dialog for the app with focus.
Created attachment 109839 [details] [review] Revision #1. This is one of those bugs where I can't reproduce it, but I think I can see where it's going wrong. Here's a patch that I hope will fix it. Please test.
Rich, I no longer can reproduce it either. I wonder if your patch related to the "cell" problem fixed it as a side effect?
You know, I bet that's it (though I haven't debugged it to prove it). Looking at your comment on bug 525644, one of the events you had to handle was: object:text-changed:delete Looking at default.py, I see: def onTextDeleted(self, event): """Called whenever text is deleted from an object. Arguments: - event: the Event """ # We don't always get focus: events for text areas, so if we # see deleted text events for a focused text area, we silently # set them to be the locus of focus.. # if event and event.source and \ (event.source != orca_state.locusOfFocus) and \ event.source.getState().contains(pyatspi.STATE_FOCUSED): orca.setLocusOfFocus(event, event.source, False)
Could be. So what do we want to do here? The "fix" is going to prevent any other similar scenerio's screwing up the app name. I suggest we apply it any how, just in case. Thanks for testing it.
(In reply to comment #7) > I suggest we apply it any how, just in case. Oh, I agree. I was just addressing the reproducibility (or lack thereof) of the original bug. :-) I do wonder though if what we do in default.onTextDeleted() is what we want to be doing. Maybe we want to check to see if we event is for a focused text area *that's in a focused/active window*???
This patch doesn't seem to cause any other problems so I think it is good to apply.
(In reply to comment #8) > I do wonder though if what we do in default.onTextDeleted() is what we want to > be doing. Maybe we want to check to see if we event is for a focused text area > *that's in a focused/active window*??? This seems like it might be a good thing to do. Without it, the side effect might be that we get a lot of verbose context output: 1) App "a" has focus 2) App "b" issues event that causes locus of focus to be in app "b" 3) App "a" gets an event that requires speech output -- the hierarchical context is completely different, so we might get lots of speech output. script.py:processObjectEvent has some rough filtering if "presentIfInactive" is False, but the default is True. :-) So, maybe we need to do a more global search for orca.setLocusOfFocus calls and make them only if self == orca_state.activeScript?
Opened bug #530568 for the issue in comment #10.
Patch committed to SVN trunk and the gnome-2-22 branch. Moving to "[pending]. Thanks.