currently I am trying to scrape some data from a web-page using the “Get Text” activity.
While the selector normally works pretty well using unique HTML attributes I now am in a dead end:
The HTML field I try to scrape data from is created after a mouse over/hover over another field.
So I thought I would take the following steps:
Hover Activity: Selector for text field A
Pop-Up appears (the div…/div part is created and appears now in the HTML code of the web page)
Get Text Activity: selector for text field B that is inside the div from step 2 (was not exisiting in the HTML code during step 1)
The problem I now have is, that the “get text” activity cannot find text field B.
While debugging I noticed that the dynamically created div and all its children does not have an uipath_custom_id attribute. So the I assume that the activity cannot find the field using the right selector.
[I assume that the Browser-Plugin is responsible for creating this attribute sothat Uipath can access the elements inside the browser]
When I use the UI-explorer I can actually watch the Firefox plugin creating the uipath_custom_id when hovering over the field using “indicate element”.
So now I assume I need to make sure that the uipath_custom_id is created when I use my “get text” activity.
How can I actively provoke a uipath_custom_id creation, so that the freshly created HTML elements are accessible by UIpath activities?
Or is there another solution to my problem (not using OCR)?
Did you figure it out? I too have problems scraping and have notice the uipath_custom_id that may be the cause for not scraping well and giving me error.
The uipath_custom_id attribute is indeed created by the browser plugin but it’s something that the plugin uses internally and offers no guarantees when it comes to predictability. So you should definitely not include it in your selectors.
Can you post some more details about your scenario? The application you’re trying to automate or some selectors would help.
@leif.lazar
first of all:
The scenario was really old (see date on original post) and it has majorly changed since then, so the problem is not exisiting anymore (for me).
But to Elaborate the intention of my post:
I do not want to use the UiPath_custom_id as a selector.
Back then I noticed that the browser Extension is only able to read DOM-parts of the HTML-webside that do have a UiPath_custom_id.
This is supposedly created when the page is loaded.
But in my case, a mousover popup was not part of the original HTML and only got added (thorugh JavaScript I assume) afterwards. This results in the whole pop-up not having uipath_custom_id Attributes and thus not being able to be accessed by UiPath (through the browser Extension).
So my idea was: “Maybe there is a way that allows me to trigger the creation of the UiPath_custom_id inside my workflow, after I have provoked the popup creation and thus making the popup accessible for UiPath selection”.
By now I do not have any Scenario anymore, but I would still be interesting to know, how the browser Extension work to get mor insides
I know the post is quite old, but I found no less than 4 similar questions on the forum, all unanswered so far, so I thought a solution might come in handy for some of the forum users.
My scenario was more or less comparable:
the bot was generating some new rows for a HTML classic table in a web app however, besides the 1st generated row, it failed to recognize (by that meaning that I couldn’t even [re]indicate the element to the bot, it was simply not “seeing” it) any other additional ones, no matter how much would I refine the selector. Anyhow, this behavior was only apparent if I had the bot operating in the app, while everything seemed to be fine when performing the same actions manually.
What was actually happening is that the UiPath chrome extension was assigning a certain “uipath_custom_id[s]” to the 1st row when it was generated, then wrongfully using the very same one[s] for any other row that followed - so it was perpetually detecting the 1st row only, no matter how many other were there.
Took a while to figure this out, but once identified, the solution that did it for me was quite simple - injecting a JS snippet on the page after each new row was generated, to remove that uipath id attribute:
"
function Remove_UiPath_IDs ()
{
var Target_Elements = document.getElementsByTagName(‘YourTargetElementTagHere’)
for (var i = 0; i < Target_Elements.length; i++)
{
Target_Elements[i].removeAttribute(‘uipath_custom_id’);
}
}
"