We encountered the situation a lot. the first time on web application didn`t work , but the second time it worked.
My analysis with Wire Shark indicates that it has something to do with the server performance as well as how QA wizard parse the package frame from browser and the web application
Whenever you run test on a new page has no cache to use, it may take extra time for the web to load,
Some time one response on your application requires more than one package from the server, which initially sends to the browser via https request, then browser parses the package and QA wizard read it. (from my Wire Shark Analysis), then the QA wizard execute the next line of code as long as it read the first package within certain time , regardless weather or not it is fully loaded.
this is for the first time: the script didn`t have enough data to make sure of control status and then it failed.
A browser has the function to store web cache, as long as it was once loaded, the browser can use cache to response according to the frame head, so that means, the second time onwards(once fully loaded) , one part of the date from you local browser, one part from the server.
That is why it didn`t wok for the first couple of times (until it is fully cached) then worked again.
Two solutions for this issue:
For front users :
1. place proper delay(600~2000) command at a proper position and whenever the browser will load another new page.
2. lengthen your browser cache period, Google online and you will know, very easy.
(note :600 ~2000 ms is a suggestion. the timer depends on your application, with wire shark, you can get the accurate ms. if you don`t know how to use or not allowed to use, then you can estimate and test it.)
keep asking if you still stuck at it.:)
Solution 2: For QA Wizard Development team
To eradicate the root issue, development from QA wizard should properly control the interaction between QA wizard and the browser. especially under what situation should QA wizard execute the next line of command