Open Bug 762769 (uia) Opened 12 years ago Updated 4 days ago

Implement UIA


(Core :: Disability Access APIs, enhancement, P3)

Windows 8





(Reporter: surkov, Unassigned)


(Depends on 2 open bugs, Blocks 3 open bugs, )


      No description provided.
Alias: uia
Depends on: 762770
Depends on: 762806
Depends on: uiatext
Depends on: 762897
Depends on: 762898
Blocks: 741750
Blocks: 806536
Whiteboard: [me
Whiteboard: [me → [metro]
Depends on: 963157
Closing as we never shipped Metro!
Closed: 6 years ago
Resolution: --- → WONTFIX
I think we still need it for Windows accessibility. Jamie, correct?
Flags: needinfo?(jteh)
Resolution: WONTFIX → ---
Whiteboard: [metro]
Yeah, we'll very likely want this in future.
Flags: needinfo?(jteh)
Priority: -- → P3
Blocks: 1764103
Type: defect → enhancement
Severity: normal → S3
Depends on: 1881190
Depends on: 1881191
Depends on: 1881195

In bug 1881195, I hypothesised that we might be able to get an early win and improve UIA performance by implementing IsControlElement, even though our UIA implementation is still based on IAccessibleEx. After that landed, I did the following test both with and without accessibility.uia.enable set to true:

  1. Opened (pretty large document) in a new window.
  2. Waited for it to finish loading.
  3. Focused an element on the page.
  4. Opened the NVDA Python Console with NVDA+control+z.
  5. Ran the following code:
    import time, UIAHandler as uh; e = uh.handler.clientObject.ElementFromHandle(nav.windowHandle); t = time.time(); e.FindFirst(uh.TreeScope_Descendants, uh.handler.clientObject.CreatePropertyCondition(uh.UIA_AutomationIdPropertyId, "foo")); time.time() - t

UIA disabled: ~4.1 sec
UIA enabled: ~3.1 sec (~1.3x faster)

For comparison, Chrome (which has a native UIA implementation not based on IAccessibleEx) takes ~0.44 sec (~9.3x faster than Firefox with UIA enabled).

So implementing IsControlElement in Firefox is a decent improvement, but things are still pretty slow.


That profile shows that UIA spends a lot of time in AccessibleObjectFromWindow (and the resultant calls to LresultFromObject and ObjectFromLresult, etc.) due to getting the fragment root to calculate the runtime id. That is really unfortunate because there's not really anything we can do to prevent or improve that while we're using the IAccessible proxy. That means the only path forward is a full native UIA implementation. :(

I do still see some calls to UIA's Acc2AttributeParser::GetAttributeValue, which does regex stuff, but I can't see what property triggered that. Still, that's taking significantly less time than AccessibleObjectFromWindow, so I'm not sure how much point there is in chasing this.

Depends on: 1886371
Depends on: 1886618
Depends on: 1886619
Depends on: 1886709
Depends on: 1886711
Depends on: 1886937
Depends on: 1887579
Depends on: 1887777
Depends on: 1887780
Depends on: 1887782
Depends on: 1887784
Depends on: 1887785
Depends on: 1887786
Depends on: 1887787
Depends on: 1887788
Depends on: 1887789
Depends on: 1887790
Depends on: 1887799
Depends on: 1887800
Depends on: 1889290
Depends on: 1892372
Depends on: 1894165
Blocks: 1777875
Blocks: 1876192
Blocks: 1890155
Depends on: 1897333
You need to log in before you can comment on or make changes to this bug.