Closed Bug 366813 Opened 15 years ago Closed 15 years ago

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

Categories

(Core :: Disability Access APIs, defect)

x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: ginnchen+exoracle, Assigned: ginnchen+exoracle)

References

Details

(Keywords: access)

Attachments

(1 file)

For atk, nsDocAccessibleWrap::FireToolkitEvent doesn't deal with EVENT_SHOW/HIDE
Should fire event state-changed:showing and state-changed:visible accordingly.
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?
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.
Attached patch patchSplinter Review
Attachment #251745 - Flags: review?(aaronleventhal)
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?
Attachment #251745 - Flags: review?(aaronleventhal) → review+
Aaron, you're right.

Bug 367337 filed.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.