Follow up from bug 366716. Ginn, you sure this is a blocker? What's the use case for the EVENT_HIDE? What events for show/hide on tooltips are going to be mapped to in ATK? Keep in mind that the tooltip accessible is always the same, and the EVENT_SHOW is a hack to make it work with MSAA, because it's what even it expects for them. However, as far as I know nobody cares when the tooltip actually goes away.

Maybe it's not a blocker. In ATK, I think show/hide mapped to state-changed:showing, state-changed:visible. I'd like to make these events in pairs.

I also noticed we're not firing EVENT_SHOW for progress bar, but we did fire EVENT_HIDE for it. Is it a potential issue for at tools?

Hi guys, A possibly related question: Does any AT currently expose the tooltip? nsXULTooltipAccessible::GetName seems to be just a stub.

ZoomText 9.1 beta does. And it's not a stub anymore: http://lxr.mozilla.org/seamonkey/source/accessible/src/xul/nsXULTextAccessible.cpp#90

(groan) Time for me to pull an update. Sorry about that!

With respect to Ginn's question about progress meters: It's a bit hacky, but we needed a way to make sure that screen readers knew when a progress meter started and stopped. We decided to use SHOW when it starts moving and HIDE when it goes away. Even if it's really an ancestor node that's being shown or hidden, the events will still always also happen directly on the progress meter, which makes it much easier to detect. Here's where it's shown: http://lxr.mozilla.org/seamonkey/source/accessible/src/base/nsRootAccessible.cpp#723 Here's where it's hidden: http://lxr.mozilla.org/seamonkey/source/accessible/src/base/nsDocAccessible.cpp#1124 If there's anything wrong with this we should file a separate bug.

Hmm, I guess we do need a separate bug since the nsRootAccessible part of the solution is ifdef'd for Windows-only.

Bug 367369 filed for progress meter EVENT_SHOW issue

Ping. :-) Right now, Orca can provide access to the tooltips that appear; while we don't announce anything (or have any desire to) when they disappear, we would like to be able to update the braille display to reflect what is showing (or not showing) on screen. We cannot do that because of the lack of events: We think the tooltip is still visible.

Mass un-assigning bugs assigned to Aaron.

Yeah I can see not having an EVENT_HIDE on tooltips would be a major pain for braille. Joanmarie have you worked around this somehow or is it still a priority? We should consider the trigger source for tooltips parents if possible.

We're not doing anything w.r.t. tooltips in Gecko because they're not keyboard accessible (in addition to this issue).

Jamie how does NVDA handle tooltips?

Err... it looks like NVDA doesn't handle Mozilla tooltips at all. We do handle native Windows tooltips, but we don't seem to handle the tooltip role generically for some reason. In any case, we only handle the show event because we just speak it. For such messages in braille, we normally pop up an alert which disappears after a configurable timeout. However, having it stay on the braille display until it disappears off screen makes a lot of sense, so yeah, the hide event would be useful for this purpose. In other words, NVDA doesn't currently use it, but I think a hide event is a good idea.

(In reply to comment #14) > We're not doing anything w.r.t. tooltips in Gecko because they're not keyboard > accessible (in addition to this issue). See bug #367364 for this issue.

AUTO-CLOSED. This bug untouched for over 2000 days. Please reopen if you can confirm the bug and help it progress.