Bugzilla

A few technical notes from looking at the profile:
- Looking at the stack chart, I see MsaaProxy() makes a call to mozilla::a11y::ia2AccessibleText::get_nSelections() (via AccUtils::get_nSelections()) and then spends the rest of its time (> 35s) in IA2ProxyTextRange::GetSelectionRange() which calls IA2ProxyTextRange::GetSelectionRangeEndpoints() followed by IA2ProxyTextRange::Endpoint::Normalize() many times. Without knowing any of the details of how those functions work, one possible explanation would be that get_nSelections() is reporting that there are a large number of selections and then IA2ProxyTextRange iterates over ... something ... many many times. The problem here seems to me to come foremost from the _quantity_ of calls into our code rather than that the calls themselves are taking a long time.
- [The page that I cited above](https://www.linkedin.com/pulse/ui-automation-incomplete-guide-builders-part-1-guy-barker) 
'While a number of UI frameworks on Windows do implement the UIA provider API, there are some cases where this does not happen. For example, if the provider process is using an older type of UI where the UIA provider API has not been implemented, yet the old MSAA data is available, UIA itself will convert the MSAA data available into the equivalent UIA data. This is done through UIA’s “MSAA Proxy”.' I do see "MsaaProxy::Text_GetSelection()" in the callstack so are we into a fallback situation here and is that expected?

A few technical notes from looking at the profile:
- Looking at the stack chart, I see MsaaProxy() makes a call to mozilla::a11y::ia2AccessibleText::get_nSelections() (via AccUtils::get_nSelections()) and then spends the rest of its time (> 35s) in IA2ProxyTextRange::GetSelectionRange() which calls IA2ProxyTextRange::GetSelectionRangeEndpoints() followed by IA2ProxyTextRange::Endpoint::Normalize() many times. Without knowing any of the details of how those functions work, one possible explanation would be that get_nSelections() is reporting that there are a large number of selections and then IA2ProxyTextRange iterates over ... something ... many many times. The problem here seems to me to come foremost from the _quantity_ of calls into our code rather than that the calls themselves are taking a long time.
- [The page that I cited above](https://www.linkedin.com/pulse/ui-automation-incomplete-guide-builders-part-1-guy-barker) says 'While a number of UI frameworks on Windows do implement the UIA provider API, there are some cases where this does not happen. For example, if the provider process is using an older type of UI where the UIA provider API has not been implemented, yet the old MSAA data is available, UIA itself will convert the MSAA data available into the equivalent UIA data. This is done through UIA’s “MSAA Proxy”.' I do see "MsaaProxy::Text_GetSelection()" in the callstack so are we into a fallback situation here and is that expected?

A few technical notes from looking at the profile:
- Looking at the stack chart, I see MsaaProxy() makes a call to mozilla::a11y::ia2AccessibleText::get_nSelections() (via AccUtils::get_nSelections()) and then spends the rest of its time (> 35s) in IA2ProxyTextRange::GetSelectionRange() which calls IA2ProxyTextRange::GetSelectionRangeEndpoints() followed by IA2ProxyTextRange::Endpoint::Normalize() many times. Without knowing any of the details of how those functions work, one possible explanation would be that get_nSelections() is reporting that there are a large number of selections and then IA2ProxyTextRange iterates over ... something ... many many times. **The problem here seems to me to come foremost from the _quantity_ of calls into our code rather than that the calls themselves are taking a long time.**
- [The page that I cited above](https://www.linkedin.com/pulse/ui-automation-incomplete-guide-builders-part-1-guy-barker) says 'While a number of UI frameworks on Windows do implement the UIA provider API, there are some cases where this does not happen. For example, if the provider process is using an older type of UI where the UIA provider API has not been implemented, yet the old MSAA data is available, UIA itself will convert the MSAA data available into the equivalent UIA data. This is done through UIA’s “MSAA Proxy”.' I do see "MsaaProxy::Text_GetSelection()" in the callstack so **are we getting into a fallback situation here and is that expected?**