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)

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).

Hi Surkov, just use nsDocAccessible::AttributeChanged(). There is no reason to create a new mechanism for this. What we have already works.

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.

Backed out for orange tbox.

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); +