Ticket #18 (closed defect: fixed)

Opened 4 years ago

Last modified 4 years ago

IAccessible NVDA objects do not cope well when event window is not the same as IAccessible's window

Reported by: mdcurran Owned by:
Priority: major Milestone: 2009.1
Component: Core Version: development
Keywords: Cc:
Operating system: Blocked by:
Blocking:

Description

IAccessible objects are instanciated in the operating system via events that include a window handle, object ID and child ID. However when the IAccessible is instanciated, the window it thinks it has, is sometimes different to the window used in the event. Usually IAccessible NVDA objects remember the window handle used in the event, both to save time and to make sure that future events for that object are caught by that object properly. However this means that if an IAccessible NVDA object was instanciated from another using one of the navigation properties, it may not have the same window handle it would have if it were instanciated by an event, meaning that equality checks will break. This problem can be seen very clearly in Mozilla Firefox2 and other Mozilla Gecko <=1.8 applications. Due to equality breaking, focus ancestors are repeated sometimes up to three times, which causes a major amount of redundant and annoying speech.

To fix, IAccessible NVDA objects should no longer cache the window handle from the event, but instead get it from either GetIdentityString? (in the IAccIdentity COM interface), or from the windowHandle property in the IAccessible2 COM interface, or failing those, from the WindowFromAccessibleObject? OLE function. As this now may mean that some events will not match their objects (e.g. a name change event on the focus object, where the event and object window handles differ), after the object is instanciated from the event, the object must be compared with the focus object to see if they are equal. If they are, then the event should be passed to the focus object and the newly instanciated object should be deleted.

Change History

comment:1 Changed 4 years ago by mdcurran

  • Status changed from new to closed
  • Resolution set to fixed

I don't think any more work needs to be done on this ticket. The over all problem has already been solved, although it may not be exactly how the ticket first described the solution. The only difference is that we're not using IAccIdentity to find out window, objectID and childID info. As much as this would be good to do, not enough MSAA implementations implement this interface, and it seems that menus get a menu handle, not a Window, which makes another exception to the usage. To top it off, the identityString given by IAccIdentity is opaque anyway, and Microsoft suggests not hacking in to it.

Note: See TracTickets for help on using tickets.