"Chrome legacy Window" when launching chrome with RunAs

Question

I am trying to use MSAA (on Win7) to get the addressbar in chrome browser and replace it with a different url. When chrome is launched normally (as the loggedon user), I am able to find the addressbar using the IAccessible interface by traversing through the UI tree of the window classes owned by the process. However, if I launch chrome as a different user (by using RunAs in windows), I see window with name, "chrome legacy window" when going through the classes owned by the "RunAs" process. The window hierarchy and the content within is vastly different from what I see if I scan the process that is running as the logged on user.

Although I can see (window classnames) Chrome_WidgetWin_0 & Chrome_WidgetWin_1 in both the browser instances, only the one running as the current user is giving access to the address bar. Any idea on what is happening when chrome is launched as a different user? Is there any workaround or should I be looking at a different technology?

Answer 1

As Penn has noted this may have something to do with the PDF view which has caused peculiar problems in the strangest of places.

Looking at the bug tracker here it looks like sporadic behaviour with PDFs and the "legacy window" has been introduced in a recent build so perhaps try rolling back to an earlier version of Chrome.

Also I presume you are using chrome://accessibility with

Global accessibility mode: on
Show internal accessibility tree instead of native: on

or starting chrome with the flag --force-renderer-accessibility it seems to be a prerequisite for other automation programs like autoit as seen here.

If you can't get this method working I'd recommend trying the autoit script there.

Here is an autoit code example that shows grabbing the address bar and using it for general navigation, upon other things!