GNOME Bugzilla – Bug 591873
Orca doesn't speak tooltips in OOo
Last modified: 2010-05-22 18:49:51 UTC
This is a spin-off bug from bug 590680. Ctrl+F1 can be used to show the tooltip for items in OOo toolbars. Orca fails to present the tooltip.
Created attachment 140825 [details] [review] possible solution The problem is that when OOo tooltips appear, an object:state-changed:visible event is emitted; an object:state-changed:showing is not. We expect the latter and are not even listening for the former. This patch adds a listener to the OOo script. Problem solved. Will: As I understand it, and based on testing this patch: The addition of the listener in the OOo script means that all scripts which are active while OOo is being used will listen for this new event. Once the user quits OOo, all of the other scripts will stop listening for it. (Right?) If so, is this event one which we'd prefer not to be listening to? (i.e. would you rather I file a bug against OOo and block this one?) Thanks!
(In reply to comment #1) > Will: As I understand it, and based on testing this patch: The addition of the > listener in the OOo script means that all scripts which are active while OOo is > being used will listen for this new event. Once the user quits OOo, all of the > other scripts will stop listening for it. (Right?) Short answer: correct. Long answer: when any script instance listens for an event, Orca will get the event notification regardless of whether the script is the active script or not. When a script instance goes away, the focus_tracking_presenter should deregister events. If there is no other script listening for an event after this happens, then the event should not be delivered to Orca. > If so, is this event one > which we'd prefer not to be listening to? (i.e. would you rather I file a bug > against OOo and block this one?) Some events are quite quite chatty. I believe the bounds-changed one in particular is pretty nasty. I'm not sure about visible, though. It might be one of those that's up there with the child added/deleted events, but the best way would be to run some regression tests and grep the debug logs for the event. Since this one is kind of an unknown and may introduce an unexpected performance penalty, I'm tempted to push this one out to 2.29.0 as well.
Sounds like a plan. I've just opened an enhancement request asking them to consider emitting an object:state-changed:showing event at the same time they're emitting the object:state-changed:visible event. Maybe they'll say "yes". <fingers crossed> In the meantime, I'm blocking this bug against that request.
Changing the status from 'blocked' to 'to verify' because the blocking bugs are marked as fixed. Note: Verification doesn't necessarily mean that Orca is doing the right thing yet; merely that in theory we should be able to implement what we need to do because we're getting the expected events and/or other information from OOo.
Cannot verify this yet. The bug still exists in OOo dev 3.3 m76. But based on experience, it takes a few dev builds for these changes to get incorporated into an externally-available build.
Verified in OOo dev 3.3 m78. Orca now presents the tooltips as expected when Ctrl+F1 is pressed. Since there is no need for us to change anything in Orca, closing this bug as NOTGNOME.