In the selector of the activity, usually there’s a html-tag with ‘app’ and ‘title’.
This gets added to the child activities, like “Click”. This is fine.
BUT, if you add lines to the selector, like “<webctrl src=…”, then this text is NOT included in the child activites.
The selectors in “Click” only uses the first line from “Use Application/Browser”.
This means in an IFRAME website, I have to update ALL activites if src-tag changes, instead of just changing the “Use Application/Browser” selector.
See image for better explanation. Please fix this.
As per screenshot looks like even the first line is not matching…the title looks different
may be it is pickignf rom the window selector in the click activity itself…can you check the same…in modern there is a separate option window selector in the properties panel
Please ignore the title tag in the screenshot as I edited it. Lets’ say title=‘home’. @Julian_Muhlbauer That’s where I put the lines. Only the first line is included in the Click activity’s strickt- and fuzzy selector. @postwick All activities are modern.
If you edit the selector (the IFRAME line) in “Use Application/Browser” activity, this should be reflected in the child activities.
I don’t see how editing the Click activity’s “Window selector” helps? Then you still need to edit every child activity.
The child activities have their own window selector. But I have never been able to get UiPath to give me any clarity on how it’s used, if it’s ignored in favor of the container activity’s selector, etc.
The simple question is…without worrying about all this does your automation work? Mine do, so I stopped worrying about these differences.
It’s weird how it seems to work in your example, but I don’t get the same result.
When I use “Single window” the IFRAME line is still added to the Click’s selector,
resulting in a selector that don’t work.
Click selector with automatically duplicate IFRAME line:
To make it work I have to remove the IFRAME line added by Click (from Strickt, fuzzy and anchors selector).
It does give me the desired result in the end but it’s a lot of work.
This problem did not exist in the old Attach browser. This is a major bug that needs to be fixed.
@postwick My consern is that I develop in another environment than production, and the website also may be changed by development. If I need to change head selectors later, I don’t want to update every single activity.
Yes, this workaround only works if you use the classic Selector Editor. If you use the modern selector editor, it will add extra IFRAME rows that you need to delete. Unfortunately you can’t access the classic editor until you have used the modern editor.
Why? Everything still works. I suspect that the greyed out portion of the selector is ignored in favor of the actual UI object (ie browser window) attached to by the container.
yeah, i dont think either that this is a functionality or behavior bug, but a QOL one.
The Windows selector and the container-type activities dont make sense together. In the selector of the objects on Object Repository, you can edit those Windows selector as well.
Its not clear when one or another will be used.
I think that, when selecctiong a field on you app, creating a new Object with a selector, then the Windows selector is used. But, when using the same object inside a activity in a container, the Window selector is ignored.
This is an old thread I posted when first using modern a few years ago. The UiPath reply about Window Selectors is basically, don’t worry about them. So I don’t.
Yes they’re there and granted, it might suggest that you need to edit them, but feel free to leave them as they are and 99.9% of the time it will work fine But noted, we’ll think about how to suggest that you generally don’t need to edit them. The "modern" activities don't make sense - #9 by Cosin
Also at the end of that thread I asked for details on how/when the Window Selectors are used, and never got a reply.
But still, it would be more intuitive if the selector in Use Application/Browser was used as head in the children activities, as it did in the old Attach browser.
I agree that it’s more intuitive, but it may not be more functional. What if the window changes as you’re going through your process? The window selector for a click 20 steps in may not be the same as the original selector for the Use Application/Browser.
But noted, we’ll think about how to suggest that you generally don’t need to edit them.
fvalencia
hentsou_mamy