Closed jaminfine closed 5 years ago
You're right. Might the problem be that we're firing the "execute" event in the first place? Maybe it really should be the "tap" event, which should not do anything on a disabled widget.
I feel like the same problem could still come up. I suspect that if the execute event can be successfully called on disabled and hidden widgets, the tap event also could.
One possibility is to assert that the widget is visible and enabled before firing the execute event. This would make the test fail before trying to click on it. This could apply to other events, like contextmenu. Do you think this is a good path to take? If so, I can work on implementing it this way
Sure, go ahead, thank you!
While recording, you are limited to only using buttons that are visible and enabled. During playback, the button is not clicked, instead the execute event is directly fired. This means that disabled, hidden, and excluded buttons can be used as if they were visible and enabled during playback.
A playback should fail if the next step is to click on a button that is disabled or not visible.
To demonstrate this issue, start with the widgetbrowser and go to the form tab. Record yourself clicking on the menubutton and then on a button inside the menu that pops up. Stop the recording. Click on the disabled button. Now, play back the recording. The events are successfully fired, so it doesn't fail, even though one button was disabled and the other not visible.