I’m working on converting some of my existing workflows that run reports in Internet Explorer to work with Edge. These workflows all run without issue in IE, but I am having a bizarre, persistent issue in Edge that I cannot get past and which will not be caught by Try/Catch blocks.
See this snippet - we have an Attach Browser activity (BrowserType is set to Edge, selector points to the tab the reports load in - all show as valid in UI Explorer), which then waits for content to finish loading before validating that the report contents match what is expected. Everything is running fine up to the “Get Text ‘TD’” activity. The selector for this validates just fine in UI Explorer.
I’m validating that the robot is reaching this point from the StatusMessage activity just above - it logs to the Orchestrator host that it has entered the try/catch block, but before the second log message that logs the exit from the try/catch, the workflow exits with the following exception -
UiPath.Core.Activities.ElementNotSetException: The target Element was not specified for this activity. You should set its Target property or use this activity inside of a scope activity (Attach Browser, Open Browser, Open Application, Attach Window, Get Active Window, Element Scope activities). —> UiPath.Core.UninitializedNodeException: The UiElement is not initialized
I’ve tried just about everything I can think of short of rebuilding the entire workflow from scratch to get around this. Does anyone have any idea why this exception is occurring, and why the try/catch isn’t catching it? The fact that every selector validates successfully in Explorer, and previous selectors in the Verify Contents Loaded sub-workflow are working just fine, has me stumped. Thanks for any ideas you can provide!
Was a Debug done and analysed at what point the Exception is thrown ? Could you maybe show us the Exception Thrown Scenario/Screenshot when the workflow hits the Exception in Debug Mode ?
I unfortunately can’t run a debug from Studio because the server these reports run on is fully sandboxed; I have to build, publish, run from the server, and analyze from logs. I’ve got a log message activity on either side of this selector inside of the try/catch and a third in the Finally, and the logs show:
first log message
-exception
-no second log message
-no finally log message
I can’t share a screenshot for the same reason but I am visually watching the execution and the report is on-screen and the selectors do test as valid in UI Explorer, despite the exception being thrown.
When checked again now the Screenshot shared, the Catch Block Sequence name is mentioned as - “try alternate selector” - Does this mean there is an a Get Text Activity present inside it as well ? Maybe that is the issue ? As there are no Try Catch blocks around that Get Text activity it might be getting faulted or not handled.
It’s just a different version of the selector with the top level of the selector explicitly stated in case the Attach Browser selector was causing the problem; however, it also has log message activities on either side that should be appearing if the catch block is being entered.
This does mean that the Get Text activity is present I believe in the Catch Block ? Then I believe that it is the one erroring out as there is no Try Catch introduced for that activity. You could try a similar Simulation in your Dev/Test Environment and check this approach.
If that was the case, the log before that activity should be appearing in the logs and it is not. The workflow never enters the catch block at all.
edit - I’ve tried commenting out the second Get Text activity and compiling everything again to give it another try. I’ll follow up once I get a result.
So there’s definitely something odd going on; I created a new workflow with the same activities, and while the exception is still occurring it is being caught as expected in the new workflow.
The issue appears to be with the selector inside an Attach Browser activity; just on its own, the selector works with no issue, but it fails when in an Attach Browser scope despite the selector passing validation in UI Explorer. As a workaround I’ll just escape this problematic section from the Attach Browser for now and see if that gets me any further.