It much depends on application under test's behavior. For most of the cases, I would use "wait for property" (like enabled, focusable...)
So you are saying that I should wait for the property on the spinner DIV to basically be hidden? The underlying controls already will have a property of enabled and focusable...unless the overlaying of the spinner div causes the underlying controls not to be focusable...?
If "target control" has any property that can distinguish its status (ready vs. not ready), I'll use that property. Else, I'll wait for spinner gone (in this case, you can implement high level action "wait for control not exists")
I also have this challenge with Angular web pages. Sometimes TA tries to click on controls too soon, before the page has fully stabilized. The controls exist but are not clickable until the opaque div and spinner are gone.
What property can be used to determine the "ready for input" status of a web control (image, link, button, etc.)? Other tools have actions such as "Wait for element clickable" or "Wait for Angular load", but TA doesn't seem to have that.
Kevin, we can take a look at available properties (TA properties/native properties) and find out their values at the time application/page is stable.
Matt Michaelsen
I'm testing an angular site where the wait icon or spinner is implemented as a div tag that is displayed over the controls while a data fetch operation is in progress. Once that is done, the div is hidden or removed and the page controls become available for interaction. The OOTB keywords such as control condition and control condition wait don't seem to apply in this situation. My question is what is the best practice in this case for ensuring that controls are ready to receive input?