User prompt triggered by action in Perform Actions should cause the command to fail with 'unexpected alert open'

[burg]

This is a straw man proposal to align user prompt handler usage with Execute Script. This was just changed so the user prompt handler is never invoked mid-command; instead the command fails with unexpected alert open' and a subsequent session command will run the user prompt handler.

It is kind of weird to expect to end an action chain with an unexpected alert open, in the sense that you'd always handle this case explicitly with an Alert-related command rather than relying on the user prompt handler. So, I'm not sure when the user prompt handler is actually useful.

Speaking to implementors' concerns, you can't interact with a page further when an alert shows up, so aborting the command keeps the state of the session sane. Interaction state (such as a gesture recognizer) is not normally maintained when an alert pops up, so it would be weird to do so for Perform Actions.

[andreastt]

cc @jimevans @AutomatedTester

[jimevans]

@burg Help me understand what your proposal is. Are you suggesting that an action chain be aborted should an unexpected user prompt appear (like a user script does now)? Note carefully that the Execute [Async] Script commands do not fail with "unexpected alert open." The recent change "returns success with data null" if a user prompt is displayed during execution of a script (or at least that was the intent of the change). The next command would fail with unexpected alert open or just silently close the user prompt and continue on, based on the value of the unhandledPromptBehavior capability.

As for what the user prompt handler is intended to solve, consider the following scenario: You're a tester who's written a WebDriver-based set of scripts to do UI-based testing on a site developed by your team. These scripts all run sequentially, but test independent things, and you only have a limited amount of machine resources (one to be exact) to run the tests on.

Now, suppose your development team has deployed a new build to your staging server, and you kick off your scripts to run. Unbeknownst to you, however, one of the workflows now contains a user prompt which appears when the user does . When your script hits the new behavior of the site, the alert appears, and your script fails because it doesn't handle the alert it doesn't know about. However, every other subsequent test also fails, because the browser has an unhandled alert displayed and can't be manipulated to do anything else until it's dismissed. The user prompt handler nicely solves this issue. It will knock down the alert, allowing the failing test to clean up, and any subsequent tests to execute.

Does this help explain the utility of the user prompt handler a little better?

[burg]

Thanks for the explanation, I understand the design better now.

Jim wrote:

@burg Help me understand what your proposal is. Are you suggesting that an action chain be aborted should an unexpected user prompt appear (like a user script does now)?

Yes, I think it should be aborted and pressed keys should be released. This is consistent with a user experience, where you need to at least click or press Return to dismiss a JS dialog. As for the error code and what would be least disruptive, I am not sure. It sounds like other endpoints are designed to silently fail by returning success. If that's really the best way forward, then so be it. I don't think it makes sense to not reset input source states.

[jimevans]

That seems a perfectly reasonable approach to me. I don't have any objection to something like that. Others should certainly weigh in on that, however.