Hi Nataly,

Yes, anything after the holidays is fine. I am making this post here, before I take a break as well so that we can revisit this.

Here I am from my personal laptop with OB Studio 1.6. I have shared a screen recording with you below.

You can see from the two locations I have thumbed down on the video, that the Element capture in v1.6 is not working. There is some kind of an error when an attempt is made to capture the Search Box on Chrome.

At the end of the clip I change the Access settings of the OB Extension. Subsequently, I restarted the Browser and retried but the recorder did not work. I have not captured the retry part in the video as it was the repeat of the same situation.

https://www.awesomescreenshot.com/video/6155297?key=f06d1068099080e7dcbc8ef78f05c631

To Summarize:

v1.5 Studio - Element capture working, but when automation runs, the step to Set text fails regardless of using XPath or Full XPath v1.6 Studio - Element capture feature not working

Thanks! Andy

Of course, for the most part the web browser commands will work a certain way regardless of the iteration. There are some updates that might change some functionality, like the inclusion of simulate and non-simulate text options, but the ability to find selectors will remain the same. If updates are made to the recorder, this will only be updated in the extension store, thus, the updates will be available for all versions of Studio.

We try to make the element extraction process as self-intuitive as possible. For most cases, the default parameters will provide enough information to interact with an element. An update our developers are making, is the ability to validate a selector without having to run the command (like we did with the desktop ui recorder). We also added the Native Browser Attach Application command to facilitate the web validation/debugging process. Our team takes in all the user suggestions to make improvements, so we appreciate the feedback.

As you mention, it would be easier to visualize the issue and troubleshoot by looking at a screenshot. I would be more than happy to connect after the holidays for a quick meeting, we can coordinate internally.

Thanks again for the feedback and happy Thanksgiving for you too!

Thanks Nataly.

That is what makes it so hard for me to understand. You are correct, these must work and it must not take you are me so many iterations regardless of which version of OB we are using.

I wish there was an easier way to post screen shots to the forums, so that I could show you the situation. I tried both XPath and Full XPath and the automation failed to find the element and the automation failed. This is different from the behavior a few days ago, when the Automation simply ran through without the Click action happening and it did not show any errors either! I don't know if updating Chrome last night has something to do with this.

On a larger front, I'm thinking if end-users have to know so much detail (about XPath, CSS Selectors) to make something work, not everyone is up to going under the hood even if they're technical, let alone Business users.

Thanks again and have a great Thanksgiving Break!

Andy,

When using the OB Recorder for Native Browser, the recorder will extract several parameter values depending on the targeted element. For most cases, the Xpath and Relative XPath fields will be present.

The Xpath field will always point to the full xpath value, while the Relative XPath will point to the relative xpath value. As default, both fields will be enabled, since most of the times this is the most reliable parameter combination. In some cases though, the user will need to use a different parameter combination, like enabling only the ID field or a CSS-Selector, it all depends on how the website is built.

In this case I indicated you a path obtained manually by inspecting the element (force of habit), but the full xpath value extracted through the recorder should also work as a reliable path to the element. You can try by enabling the xpath field with the value: "/html/body/c-wiz/div/div[3]/div[3]/div/div/div/div[1]/input[2]". Make sure you disable all other fields.

One thing to note, is that I've tested this functionality using Studio v1.6.1. In this version, we provide the user the ability to set the Set Text command as a simulate or non-simulate type. I'll run some tests on v1.5 and update you promptly.

Hi Nataly,

I did respond to your post via email, but it looks like the forums are not set up to receive email responses. I am back to the OB version 1.5.

Just to clarify: I am using OB v1.5. The Click type is non-simulate. This morning, I tried to change the XPath selector to the one you pointed out. The Dialog refuses to save with several errors.

This is what I see:

If I got to Google Page Inspector and select "Copy XPath", I get this: //*[@id="yDmH0d"]/c-wiz/div/div[3]/div[3]/div/div/div/div[1]/input[2]

If I did "Copy Full XPath", I get this: /html/body/c-wiz/div/div[3]/div[3]/div/div/div/div[1]/input[2]

I switch back to the Native Chrome Get Text Command in OB Studio, and then using the OB screen capture feature in the Get Text dialog box, I select the Search Box on the Google Finance page. When the element is selected, the XPath attribute of the Get Text dialog has this value in it:

"/html/body/c-wiz/div/div[3]/div[3]/div/div/div/div[1]/input[2]"

The Question becomes:

Why is the OB Screen Capture putting "Full XPath value" into the "XPath" attribute?

I am asking because the test on your end was successful using the "XPath" and not "Full XPath". If that's the case, users will have to keep changing the default XPaths assigned by the Screen capture in Studio. How can regular users cope with this?

Thanks, Andy

Hi Andy!

I've ran a test on the google finance site and was able to set text to the search bar. I used the Native Browser Set Text command, non-simulate type, and set the xpath field to the following value: "//*[@id='yDmH0d']/c-wiz/div/div[3]/div[3]/div/div/div/div[1]/input[2]"

Please try running the command with the above configuration and let me know if it works. I believe the issue you describe is related to the simulate setting, as some websites do not allow that type of interaction.

In regards to the [enter] action, this is also related to the specific site. Our dev team will inspect the element and update the recorder scope if possible. As a workaround, the Send Advanced Keystroke command can be used to send the ENTER key to the specified window.

Hello,

I seem to be having issues with the Native Chrome Automations. I don't know if anyone has tried this with the Google Finance https://www.google.com/finance/ ?

Here are some of the issues I'm facing:

When I type text in the Search box, the text looks like a shadow instead of a typed in text Special Key combinations are not working. For example: If I type in: StockSymbol+"[enter]", the action to hit Enter does not happen, the Script simply steps to the next line without any errors.

I have enabled/disabled the extension and restarted the Browser multiple times and yet, I can't seem to get it to work.

Thanks!

Hi, The error appeared when running the command.

But I already solved, as you told me, the extension on Studio was missing... thanks a lot !!!

Hello Ivan,

Does the error appear when using the Native Recorder or when running the command?

Please verify that you have installed the Chrome extension on Studio > Options > Extension Manager. Also, install and enable the OpenBots extension in the Chrome Store. Once installed, exit and restart Chrome to make the changes effective.