366813 - [atk]nsDocAccessibleWrap::FireToolkitEvent doesn't deal with EVENT_SHOW/HIDE

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[Ginn Chen]

For atk, nsDocAccessibleWrap::FireToolkitEvent doesn't deal with EVENT_SHOW/HIDE
Should fire event state-changed:showing and state-changed:visible accordingly.

Comment 1

[Aaron Leventhal]

Not that internally EVENT_SHOW and EVENT_HIDE usually mean that an object is being created or destroyed. Only in the tooltip case does it mean that it already existed and is being made invisible. It's further complicated by the fact that I'm not sure how to detect when the tooltip really is hidden or not -- CSS visibility doesn't seem to be the mechanism for that.

What we probably need to do is us nsIAccesssibleEvent::EVENT_CREATE/EVENT_DESTROY for all of the non-tooltip show/hide events we fire, and then have an nsEventMap.h similar to nsRoleMap.h.

In MSAA we would then do:
CREATE->SHOW (use this because actual CREATE/DESTROY events in MSAA cause problems)
DESTROY->HIDE (use this because actual CREATE/DESTROY events in MSAA cause problems)
SHOW->SHOW
HIDE->HIDE

In ATK we would do:
CREATE->child_added
DESTROY->child_removed
SHOW->state_change
HIDE->state_change

Does that make sense?

Comment 2

[Aaron Leventhal]

Actually if we do the nsEventMap.h it should be part of a generally event rearchitecture to clean things up and make things consistent across nsIAccessible implementations, as we did for roles. We might need to fix this bug before we can get around to doing an nsEventMap.h.

Comment 3

[Ginn Chen]

Attachment: patch

Comment 4

[Aaron Leventhal]

Comment on attachment 251745 [details] [diff] [review]
patch

Ginn, something which is scrolled off could be VISIBLE but not SHOWING, correct?

That means if it gets hidden by a DOM call then we'd be firing 2 state change events when we should only be firing one.

Seems like a small thing which is hard to fix. Will you file a separate follow-up bug on that?

Comment 5

[Ginn Chen]

Aaron, you're right.

Bug 367337 filed.