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.