Env: Firefox 3 investigated this and found the following: 1. Firefox fires SYS_MENUPOPUPSTART Msaa events when a tooltip is displayed. The role is ToolTip but the event carries no text information; the location information seems to be ok. 2. ZoomText processes EVENT_OBJECT_SHOW for the window class "#32774" - the system tooltip. It also does some processing in the windows hook code for windows of class "tooltips32". Thus, FireFox is not providing the data and if it was, ZoomText would ignore it anyways. So in order to support tooltips in FireFox, two things are needed: 1. We would suggest that FireFox fire EVENT_OBJECT_SHOW events rather the SYS_MENUPOPUPSTART events. The menu events result in a lot of unnecessary overhead and cause ZoomText to react as if a menu is open. Also, of course, the tooltip text needs to be added to the event. 2. FireFox AHOI would then need to be modified to support the new event.

We may need to create an accessible name for tooltip accessibles that is essentially the concatenated text of all the descendents.

Ginn, does this give the right event/name for ATK as well?

I think so. But there're some bugs blocking this. 1) nsDocAccessibleWrap::FireToolkitEvent doesn't deal with EVENT_SHOW/HIDE Do we fire EVENT_HIDE for tooltip? 2) libgail fires statechange:showing, visble, iconified for tooltip window But the role is WINDOW not TOOLTIP I'll have a look on these.

For 2), I think libgail fires redundant events for GtkWindow is not a big deal. I didn't find a good way to get rid of them. And we have to depend on libgail to create accessibles for FilePicker. We need to fix 1) for atk.

Ginn, I suggest follow-up bug for that so we can get this fixed for ZoomText testing. ZoomText development is almost finished.

sure, bug 366813, bug 366815 filed.