Starting with Chrome and Edge v117 we are seeing a new bug that affects Active Accessibility support for web pages that contain IFRAMEs or PDF documents.
This bug means that <ctrl />
selectors for those web pages might fail.
Available workaround
If you are affected by this issue, the immediately available workaround is to start the browser with this flag added to the command line:
--force-renderer-accessibility=complete
Since UiPath.UIAutomation.Activities v23.8.0-preview this can be easily done from Project Settings:
Project Settings → UI Automation Classic → Browser → Extra arguments for OpenBrowser Chrome/Edge
Notes:
- This setting applies to both the Classic OpenBrower and the Modern UseBrowser.
- To ensure that this flag takes effect for Edge the Startup Boost must be disabled. This can be done from edge://settings/system or using the StartupBoostEnabled Group Policy.
Code fix
A code fix for this issue will be included in UiPath.UIAutomation.Activities v23.10.0-preview, which is scheduled to be released next week.
This fix will remove the need to add the --force-renderer-accessibility=complete
flag when starting the browser.
However, if you are affected by this issue we strongly recommend keeping this flag to avoid issues such as this in the future.
Why is the --force-renderer-accessibility=complete
flag not added by default?
Enabling the support for Active Accessibility in the browser causes a slightly higher memory consumption.
To avoid this overhead the UiPath.UIAutomation.Activities enables support for Active Accessibility only when needed - e.g. when searching for browser UI elements using <ctrl />
selectors.
However, adding the --force-renderer-accessibility=complete
flag force-enables support Active Accessibility, and it will help guard against issues such as this in Chrome/Edge v117 and this in Chrome/Edge v114.
Further info regarding this bug
This bug was caused by this Chromium change:
[A11y] Fix for longstanding hypertext errors
We are going to report this issue as a Chromium bug, but from our past experience we expect that it will be a while until this bug is fixed in Chromium.
Below is an example of a selector that is affected by this bug.
<wnd app='chrome.exe' cls='Chrome_WidgetWin_1' title='HTML Iframes - Google Chrome' />
<ctrl name='HTML Iframes' role='document' />
<ctrl name='W3Schools HTML Tutorial' role='document' />
<ctrl name='HTML Tutorial' role='document' />
<ctrl name='JAVASCRIPT' role='link' />
Repro steps:
- Make sure that Chrome v117 is completely closed
- Open Chrome and navigate to
https://www.w3schools.com/html/html_iframe.asp
- Validate the selector from above using UiExplorer
- Observe that it fails to match the target element → this is the bug
- Refresh the web page
- Validate the selector from above using UiExplorer again
- Observe that it now matches the target element.