Closed Bug 255088 Opened 20 years ago Closed 17 years ago

Fire state change events for DISABLED (MSAA) and SENSITIVE (ATK)

Categories

(Core :: Disability Access APIs, defect)

Sun
Linux
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: korn, Assigned: aaronlev)

References

(Blocks 2 open bugs, )

Details

(Keywords: access, Whiteboard: AP2)

Attachments

(1 file)

1. Launch GOK
2. Launch Mozilla with some page
3. Follow a link to some other page
4. Bring up the GOK Toolbar keyboard.  Note that the Back button is enabled
5. Manually click on the back button in the Mozilla toolbar
6. Note that now the toolbar itself has an unavailable "Back", but "Forward" is
now enabled.  Note that this change isn't reflected in the GOK UI-Grab keyboard.
 This is almost certainly because Mozilla's toolbar buttons aren't firing
AccessibleState change events.

Note: the correct way to test this is by clicking on "Back" on the GOK keyboard,
but that doesn't work due to another bug (#255076)
Whiteboard: AP2
Assignee: aaronleventhal → Louie.Zhao
Keywords: sec508
Blocks: keya11y
Assignee: Louie.Zhao → aaronleventhal
Blocks: xula11y, htmla11y
No longer blocks: keya11y
Summary: Toolbar status changes updates not being properly fired via accessibility API → Fire state change events for DISABLED (MSAA) and SENSITIVE (ATK)
Blocks: lsr
Depends on: 374711
Assignee: aaronleventhal → surkov.alexander
How do we want to keep this?

1) by using nsIDocumentObserver::ContentStateChanged() for NS_EVENT_STATE_ENABLED/NS_EVENT_STATE_DISABLED constants
2) by looking at @disabled attribute or something like.

If we'll choose ContentStateChanged() approach then it may be intersected with ARIA disabled attribute handling (though I'm not sure now how).
Version: 1.7 Branch → Trunk
Hi Surkov, just use nsDocAccessible::AttributeChanged().

There is no reason to create a new mechanism for this. What we have already works.
Assignee: surkov.alexander → aaronleventhal
Comment on attachment 262008 [details] [diff] [review]
Fire 2 state changes for change in [anynamespace]::disabled -- STATE_ENABLED and STATE_SENSITIVE


>+    // Checking the namespace would not seem to gain us anything, because
>+    // disabled really is going to mean the same thing in any namespace.

Not sure in any (probably XUL and XHTML only :). For example, AFAIK xforms doesn't use @disabled. IIRC they use :disabled pseudo element. But I guess it's ok to handle XUL and XHTML at this momemnt.
Attachment #262008 - Flags: review?(surkov.alexander) → review+
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Backed out for orange tbox.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Checked in again but with 2 separate nsCOMPtr's for the events in order to avoid leak.

+    nsCOMPtr<nsIAccessibleStateChangeEvent> event =
+      new nsAccStateChangeEvent(targetNode,
+                                nsIAccessibleStates::EXT_STATE_ENABLED,
+                                PR_TRUE);
+    FireDelayedAccessibleEvent(event);
+    event = new nsAccStateChangeEvent(targetNode,
+                                      nsIAccessibleStates::EXT_STATE_SENSITIVE,
+                                      PR_TRUE);
+    FireDelayedAccessibleEvent(event);
+
Status: REOPENED → RESOLVED
Closed: 17 years ago17 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: