Error : InError set by the client. Client Error: Cannot read property 'focus' of undefined

Hi Yan Jun,

It is hard for me to relate both errors at this point and I will need your help to reproduce the issue on my end. Please create a sample Test Studio project and attach it zipped to this thread. I will investigate it and advise you further.

In general, the Focus option applies only for actions that require the element to be scrolled into view. There might be something that is preventing this action on the specific page, or against a certain element and I would like to test it out.

Thank you for your cooperation in advance.

Regards,
Plamen Mitrev
Progress Telerik

Hi Plamen,

Noted on your explanation for the focus option. This problem happened when I am handling DropDown. Initially i had this problem for a step to perform keypress with focus option enabled and i can reproduce the error by entering text using SimulateRealTyping into the textbox in the dropdown. I have found a workaround for it ,which needs to click on the textbox first and do the keypress and clicking it again before performing another keypress. However, the keypress can only be done by using the coded blind typing method such as "Manager.Desktop.KeyBoard.KeyPress(Keys.ControlKey);  ". 

This error only happens in one screen(Item Code)  for now because I have tried the steps that is not working on other screen (WCMF & GST) and it works.

I also experienced that this method i am using now need to use the step "click" on the dropdown for some screen(WCMF) to make the following steps after that works. I cannot use the "KendoInput: Toggle Combo" as what is the default action recorded by test studio when clicking the dropdown in recording session. Using "KendoInput: Toggle Combo" will give me unexpected action(pressing control key makes the dropdown option disappear, supposedly not) but the Step is marked as passed in the execution result. The same steps using toggle combo in other screen ( GST) works perfectly.

As a summary for my questions:

1. Is there anyway I can avoid to use the code to do blind typing? Or is there any other suggested way to handle the dropdown efficiently and effectively as I am trying to standardize the way i am handling the dropdown for the whole application under test.

2. May I know why the exact same step for almost the same element in different page behave differently related to the error from my first post? Is it because of the structure of the element in the DOM or something else?

3. May I know why the following steps after clicking/toggle combo behave differently based on the step click or toggle combo? Is it also related to the structure of the DOM? What is your suggestion for this?

I have attached the DOMs' for the screens, sample project with test cases to interact with different screens, and also some screenshots of the results. The file names are named after the screens (WCMF, GST,Item Code) with a bit description for your reference.

Hope to hear from you soon.

Thank you.

Update for the previous reply:

I have no problem using toggle combo with the method of using keypress in the GST screen. This screen DOM is already included in previous reply's attachment.

Attached is the execution result for your reference.

Thank you.

Hi Yan Jun,

Thank you for sharing details and the recorded project for investigation. It seems to me that the DOM trees do not match the state of failure of the application and were not exported from the step failure details. As a result I am not able to find the elements "Status_DD_TB0" from Item Code test anywhere in the DOM tree. I am not sure if they were actually available during the execution of the step that uses them, because they are probably dynamically loaded on the page. Please use the export feature to make sure that the DOM tree is from the state of failure.

In general, troubleshooting such inconsistent behavior against the same kind of elements against application that I can't access is hard to do. That said, I explored the recorded test and screenshots and I have a few notes and suggestions. Please find more details below.

• I believe that the target element from step 23 in Item Code test is not available in the DOM tree, or that element does not support focus option. It might be the case, if the element is not visible or hidden. Please gather the generated step failure details from Test Studio and send them over.
• I am not sure what is the benefit of the Ctrl keypress action in this test scenario. Could you, please, elaborate on this?
• You mentioned that the different pages have different behavior. This might be specific to the page structure and implementation. At this point, I can't say what are the differences and causes for this misbehavior, because I am not able to explore the application under test. Analyzing it with a static DOM tree is not a good way to troubleshoot such issue. Is there an option to allow me temporary access to the application under test, or simulate the same issue on a publicly accessible application. Please share a sample project that I can run on my end.

My suggestion is to try and simulate the issue against a publicly accessible application, so I can investigate it on my end in more details. This way we can be on the same page and find a solution quicker. If that is not an option, please capture the requests that this test scenario generates from the following executions, using Fiddler.

1. Manually execute the test scenario once against both a working and not working page and capture the traffic in different files (total of 2 scenarios here).
2. Run the test with toggle step and with a click step against both pages, again capture them in different files (total of 4 scenarios here).

I will try to recreate the page from those requests and try to analyze it further. I am not certain that this will work, but it is an option that we can try, if there is no way to gain access to the application under test, or reproduce the issue somewhere else.

Thank you for your continuous cooperation in this discussion.

Regards,
Plamen Mitrev
Progress Telerik

Hi Plamen,

Thank you for your reply and mentioning about the element in the DOM are probably dynamically loaded on the page. 

I will summarize my replies below:

1. Why i am using the Ctrl keypress action is to make the execution faster. The text box in the dropdown need the use of SimulateRealTyping to activate the filter action, If i just enter the text without SimulateRealTyping and only press ctrl, this will save time in waiting for the tool to type a long text.

2.We are open to give you access to the application under test but we can only give you access by online meeting. If the materials in the attachment are not enough to help you, perhaps we can arrange a session?

3.I cannot find a publicly accessible application which has the same criteria for all of my scenarios thus i cannot simulate this issue on a publicly accessible application.

4. I have gathered all the materials that you asked which are .SAZ files from Fiddler, Step Failure details from the execution and also the DOM tree that includes the hidden element.

I checked with the DOM that is inside the Step Failure Details but it seems that the element is not there too, so I tried to get a static DOM from the screen by pausing the script execution after I clicked the drop down and the element exist at this time. I hope this might help you in understanding this problem.

As for the .SAZ files from Fiddler, this is my first time using it. Hopefully the information in the files are sufficient for you to help you troubleshoot this problem. Please do tell me if there is something wrong with the files. I have captured the request and traffic from the 3 same screen as before for your reference.

I have uploaded the zip file in this cloud folder due to the maximum attachment size. This folder is shared to us by one of your colleagues. The name of the file is StepFailureDetails,DOM&Fiddler.zip .

Thank you for your continuous cooperation in this discussion.

Best Regards.

It appears that I don't have access anymore to the cloud folder in the previous reply. I am not sure if you can retrieve the file or not.

I have prepared another link below for you just in case you cannot access it.

https://we.tl/t-PNo1J4Ewc0

Thank you

Hello Yan Jun,

I appreciate your help with the issue. I am not able to access the shared location, but I provided you a new OneDrive location here. Please upload the necessary resources or split them and attach them in 2-3 replies in this thread.

It seems to me that you have found a way to improve the behavior for that specific scenario, by pressing the Ctrl key. I would not recommend it, as this is not tested on our end and it is actually not part of the real user behavior. If that works for you, however, feel free to use it.

Our next steps would be to analyze the attached resources and investigate the application's DOM trees and behavior. I hope that the .saz files will allow me to simulate the test scenario and better understand the issue. Then I will do my best to advise you further and that does not exclude an online meeting, if we need to interact and troubleshoot the application live. That said, I will appreciate if you can record a short video of the test execution in a working and failing scenario.

I am looking forward to hearing from you.

Regards,
Plamen Mitrev
Progress Telerik

Hi Plamen,

I have uploaded the necessary resources in your shared OneDrive.

Yes I agree with you that pressing the Ctrl Key is not part of the real user behavior. I encountered a different behavior when I am executing using IE when it is supposedly working. Thank you for pointing this out. For now i might use this method in Chrome only until we have found why do these difference in behaviors are happening.

I have also uploaded the videos in the shared OneDrive. I recorded every single possible scenario and hopefully it might help you in troubleshooting this issue.

Thank you for your continuous cooperation in this discussion.

Best Regards.

Hi Yan Jun,

I explored the attached videos, step failure details and DOM trees in different states of the application. I am not sure what is causing the different behavior.

I noticed that the fields in the different tests are not the same and thus there might be different implementation. For example, the Active/Closed dropdown has 2 options that are organized as a list with those 2 options. In cases like this, I believe that the best option is to directly click on the item from the list. This is why I modified the "Item Code -DataEntry" test to click on a new element "Progress_clickClosed". If you inspect the element, you will see that it finds the parent element with id=Status-list and then the one with textContent=Closed under it.

There are 2 scenarios that you can try with the above mentioned change. Please import the attached test to an existing project and run it with step 15 and 16 enabled. This should toggle the input combo and then click on the Closed option. Then try to switch to the second scenario, by disabling step 15 and 16 and enable 18 and 19, which click the status list and make a desktop click on the Closed option.

In case the above mentioned test scenarios fail, please explore the step failure details, as you might need to adjust the element's find expression for Progress_clickClosed. Try to adjust it to find and click on the correct element on the page and share those details for further investigation. I understand that you prefer to filter the items, especially when there are many choices. But in this case, that should help you automate this scenario.

I am happy to know that the execution against IE works for you and I hope that the above suggestion will help you as well. I would like to continue investigating the difference in the behavior. I understand that it is not possible for you to provide access to the application under test, but if you can reproduce it against a publicly accessible application, that will certainly help me.

Thank you for providing additional details and resources for the investigation.

Regards,
Plamen Mitrev
Progress Telerik

Hi Plamen,

I am happy to say that there is no failed step in both of your scenario after i adjusted the element's find expression for Progress_clickClosed.

I have a few concerns for this method. Please find it below:

1. Since this is working, does it means that we cannot standardize the way we handle all dropdowns in this application under test? This could be a problem for us considering the maintainability in a long run.

2. Why did you pair up clicking the status list with desktop click on the Closed option instead of the normal click step on the Closed Option? Is there a specific reason for this?

3.Before this I already used this method for the dropdown that is in a table that need to click the cell first to be able to click the dropdown. I faced this issue where the tool cannot find the option that i want. After analyzing, it turns out the option did not exist directly after I click the dropdown. The maximum number of list item that appears in the DOM is 31(for that screen) and the option that I wanted to click is the 40th option. So i had a workaround to use while loop that checks that if the option not exist, use keypress down 31 times on the dropdown's textbox. And the next step after the loop is to click the list item. 

Is this a correct and stable workaround? Do you have any other suggestion for this kind of case?

4. There's this one concern where the dropdown is not mandatory for our application under test. In the data source, the column might be blank/filled with NA text. This might lead to a step failure and caused a false positive result to our result execution as the step is trying to find the list item with textcontent which is blank OR NA from the data source ,which does not exist in the list. Although we can use ContinueStepOnFailure, we don't want to mess up the execution result on purpose if possible because this will take extra effort in checking the result to know if something goes wrong when everything is well. The checking of the execution result might prone to human error because of the expected failed step.

I am aware that this issue might be overcome by using test list execution result because we can see easily which step that failed, but for now, we are not ready to use test list yet because we encountered many unstable execution before. We chose to go for the more stable execution which is quick execution from the test case view.

Do you have any other suggestion for this kind of case?

5. It seems there is a bit misunderstanding from my previous reply. I would like to point out that the execution of the ctrl & enter keypress did not work as expected in IE although all the step passed before. After sometime, I found out that I need to either add manual execution delay (waitFor 2-3 seconds) between the enter text & ctrl keypress & enter keypress to make it work as expected in IE OR make a longer execution delay for all steps.

May I know why this is happening? Is it because the execution in IE is faster? It seems to me that it is faster than Chrome execution. With the same execution delay for all steps, and up until the same step, it took only 16 seconds for IE while it took 24 seconds for Chrome.

6. Our reason on why we prefer to filter the items is related to number 1,3 and 4. We chose to use the method clicking the list item at the first place, but because of these concerns, that is why we preferred to filter the items. Hopefully these information is enough for you.

Thank you for your continuous cooperation in this discussion.

Best Regards.

Hi Yan Jun,

I am glad to hear that the suggested approach is working for you. Although it might not be ideal for every situation, I am still confident that it is the better way to select an item from the drop down. That said, we can find how to improve it further and make sure that it works for most or every test case.

I will try to cover all of your questions and concerns in the order you listed them. Please find more details below.

1. The approach with clicking the element instead of using the Enter keypress is, in my opinion, more reliable. You should be able to implement it throughout those similar test scenarios and standardize it. I assume that your concern comes, when the item is not loaded/visible in the dropdown and this is why you type text to filter it. To fix that, you can try to enter the text with simulateRealTyping and add an execution delay right after that. This additional time should allow the application to load the filtered items and then follow up with a click action on the correct element.
2. I wanted to showcase all possible options to open the dropdown and click the element. This is why I used both Click and Desktop Click in different scenarios, but you can feel free to test the different combinations and find the best one for you.
3. I am not familiar with the way the application under test loads the items. If there is some kind of filter, you can refer to the suggestion in point 1. Otherwise, you need to scroll down the list and have the items loaded in the DOM tree. I might be able to advise you further, if you can find a sample page that reproduces the same behavior.
4. The functional test should have a stable workflow with expected behavior. If the test is looking for an element with blank textcontent and it does not exist on the page, the test should fail at this step. In this case, I would advise you to redesign the test or data in a way to avoid this from happening. If I have misunderstood you in any way, please share more details and a sample project or scenario.
5. The different browsers and machines actually load the application for different amount of time. As a result, you can see different loading and execution time. If you plan to run the same test against multiple browsers, please add the sufficient execution delay that will cover all browses and execution machines. Another option is to use WaitForExists step, before the action step. The benefit here is that Test Studio will constantly check for that element, until it appears in the DOM tree and continue with the execution right after that. For example, the WaitForExists step will take 2-3 seconds for IE and more or less for other browsers, instead of a fixed time.
6. I hope that the above suggestions will help you optimize and improve the behavior of the test and standardize them.

I am looking forward to hearing from you, if you have good news about the test optimization, or you need any further assistance. Please share some sample for the encountered issues to help me understand.

Thank you for the questions and details you provided.

Regards,
Plamen Mitrev
Progress Telerik

Hi Plamen,

Thank you for your replies before.

After trying to find the root cause for the issue and error earlier,  I would like to summarize my replies below:

1.It appears that by using the step Click is more stable than Toggle Combo for most of the dropdown in the AUT. As of now, we will stick to only use Click Step for the dropdown in the AUT.

2. As the cause of the error from the subject of this thread, I have found that this is caused by length of the page. If the page can be scrolled, and I am using SimulateRealTyping/Clicking, I would need to make sure all of the step related to SimulateRealTyping/Clicking's ScrollToVisibleType feature to "ElementBottomAtWindowBottom" in that screen.

This is still okay because I can still figure out what to do about it. The problem also happened even when I am not using any SimulateRealTyping/Clicking but if I am using the step Keyboard(Keypress) instead. This error happened because in that step, there is a scrollToVisible action but it is not visible in the properties of the step. So i went into the code and confirmed that there is a ScrollToVisible action without any parameter for it.

I think it would be best if there is a feature to control the ScrollToVisible action for Keyboard(Keypress) step like it can be controlled in the Enter Text(SimulateRealTyping) step.

3. Considering all of the problems, we have come out a few possible workaround for us, which either 

    a.Click Span, SimulateRealTyping and click list item

    b.Click Span, SimulateRealTyping and press Enter in code

    c. Click Span, Enter Text without SimulateRealTyping, press Ctrl and Enter in code

    d. Either one of above but fully in code for standardized way of handling drop down in this AUT.

Thank you for your continuous cooperation. I will update you if there is anything else regarding this.

Best Regards.

Hi Yan Jun,

I am happy to know that we reached together to different solutions for this automation. Thank you for making a great summary of the misbehavior and how it is working for you for each case.

I created a public feature request on your behalf to add the ScrollToVisibleType option for Keyboard (KeyPress) steps. We have another feature request to add this option for some steps that are recorded with translators and we will try to focus on that for our future releases. Thank you for your feedback on that.

My understanding is that you can continue with the automation and use the listed approaches. If that is not the case, please let me know and I will be happy to continue our discussion and think of different solutions.

Thank you for your understanding and cooperation.

Regards,
Plamen Mitrev
Progress Telerik