Hi
@CU29050651-0,
The core diagnosis is correct. Chrome's security model blocks cross-extension DOM access. When Power Automate Desktop injects JavaScript into a page, another extension (password manager, ad blocker, LastPass, Grammarly) intercepts or creates iframe elements, and Chrome throws that error because PAD cannot access a chrome-extension:// URL belonging to a different extension.
Disabling all other extensions will fix it in most cases.
What the post misses
The "disable everything" approach is not practical in enterprise environments. A few more targeted fixes worth knowing:
Run Chrome in a dedicated automation profile. Create a separate Chrome profile with only the Power Automate extension installed. Use that profile exclusively for your desktop flows. This avoids touching the user's main browser setup.
Check for iframe injection first. Before disabling extensions one by one, open DevTools on the target page and look at the DOM. If you see injected iframes from extensions like Honey, Grammarly, or any password manager, those are the likely culprits. Disable them individually rather than all at once.
Use the "Wait for page load" action before JavaScript execution. Sometimes the error surfaces because PAD runs the JS before the page is fully stable, and a loading extension element gets caught mid-render.
Consider switching to Selenium IDE actions or the built-in UI element actions where possible. JavaScript injection via PAD is fragile by design because it depends on the browser state at runtime.
The broader point
If you are building PAD flows for production use in an organization, a dedicated Chrome profile with a locked extension list is the right architecture, not a workaround. The post treats this as a one-time fix. Treat it as a setup standard.
Thank you!
Proud to be a Super User!
