GNOME Bugzilla – Bug 481809
Orca doesn't always present tooltips
Last modified: 2007-11-13 18:55:24 UTC
In the process of writing Firefox tests I discovered we weren't presenting tooltips even when that user setting was set to True. I discovered upon further investigation that we had stopped speaking them in GTK apps. Seems that gtk tooltips have been worked on: http://svn.gnome.org/viewcvs/gtk%2B?view=revision&revision=18418 and lost ROLE_TOOL_TIP in the process. :-(
Created attachment 96405 [details] [review] take 1 1. Create a new handleTooltip() in default.py that contains the logic that was in onStateChanged() 2. Add handling for the new gtk tooltips. We should probably file a bug against gtk (unless of course they used the window type hint and we're just not getting the hint, in which case we have an open Gail bug for that). So this part is more of an "in the meantime" fix. 3. Add handling for tooltips in Gecko. Not surprisingly, there are issues: Lack of (properly-timed) events to let us know tooltips have vanished. No keyboard support. I'll file those bugs....
> 1. Create a new handleTooltip() in default.py that contains the logic that was > in onStateChanged() Seems like a good idea. > 2. Add handling for the new gtk tooltips. We should probably file a bug > against gtk (unless of course they used the window type hint and we're just not > getting the hint, in which case we have an open Gail bug for that). So this > part is more of an "in the meantime" fix. I'm kind of nervous about this portion of the patch. It seems to match on a hierarchy that might be inadvertently replicated in something without a tooltip. I'd opt instead for filing a bug with GTK+ noting the regression and marking this bug as [blocked] against that bug. > 3. Add handling for tooltips in Gecko. Not surprisingly, there are issues: > Lack of (properly-timed) events to let us know tooltips have vanished. No > keyboard support. I'll file those bugs.... Thanks!
> I'm kind of nervous about this portion of the patch. It seems to match on a > hierarchy that might be inadvertently replicated in something without a > tooltip. I'd opt instead for filing a bug with GTK+ noting the regression and > marking this bug as [blocked] against that bug. Understood and done. Should I rework the patch to eliminate that, leaving the original functionality in place and adding the Gecko support, or shall we just hold off on this until the gtk and firefox bugs are fixed?
> Understood and done. > > Should I rework the patch to eliminate that, leaving the original functionality > in place and adding the Gecko support, or shall we just hold off on this until > the gtk and firefox bugs are fixed? I think we should wait and see what falls out from GTK+ and Firefox. Who knows what decision they will make. :-(
> I think we should wait and see what falls out from GTK+ and Firefox. Who knows > what decision they will make. :-( Sounds like a plan. BTW it's no longer a GTK+ bug. They reassigned it to atk/gail: > Rather, gail needs updating to set ATK_ROLE_TOOLTIP for the "gtk-tooltip" > widget name in gail_window_real_initialize(). (The widget name used for the > old tooltips was "gtk-tooltips").
Joanie and I worked on a patch and submitted it to gail. With the patch, Orca works again without needing to be modified.
The blocking bug for this (bug 482295) has been fixed for GNOME 2.20.1: http://svn.gnome.org/viewvc/gail/branches/gnome-2-20/gail/gailwindow.c?r1=1287&r2=1289 I think we can close this bug. What do you think, Joanie?
Sounds good. Marking this one as a dup of the one that resolved the problem. *** This bug has been marked as a duplicate of 482295 ***