User prompt handler should not dismiss prompts unless specifically configured

[jgraham]

In chapter 18. User Prompts:

missing value default state
not in the table of simple dialogs

    Dismiss the current user prompt. 

This means that you can never get an unexpected user prompt error and then use the /alerts/ endpoints to interact with it.

[shs96c]

This is intended. The rationale is that people will write code that expects everything to work properly, and won't be expecting the unexpected alert, and so won't have error handling code in there. Returning the error allows these users to be aware that something untoward happens, and the dimissal of the prompt means that the next command will work as expected.

For example

@Test
public void thisHasAnAlert() {
  driver.get("http://example.com");
  WebElement element = driver.findElement(By.name("q"));
  // Alert opens because of this interaction
  element.click();
  element.getText();  // Exception thrown here. 
}

@Test
public void shouldReuseTheDriver() {
  // Test runs as expected because the user prompt is already dismissed.
  driver.get("http://example.com");
}

[jgraham]

It seems like there ought to at least be an opt-in method of not auto-handling alerts. AFAICT the alert API is mostly useless; it relies on you doing a thing that you know opens an alert and then carefully not running any other commands. You can't be notified that an alert was opened and then inspect it.

[andreastt]

The logical consequence of way the specification is written now, means we can remove all the alert related endpoints because the user prompt will always either be dismissed or accepted. At the point of the next command, there will be no prompt to interact with.

I also think there needs to be a way to opt out of this.

[shs96c]

If the user doesn't specify an unhandled prompt handler, then you can interact with prompts. If the above example had been written the user will have interacted with things properly:

@Test
public void thisHasAnAlert() {
  driver.get("http://example.com");
  WebElement element = driver.findElement(By.name("q"));
  // Alert opens because of this interaction
  element.click();
  Alert alert = driver.getAlert();
  System.out.println(alert.getText());
  alert.dismiss();
}

The "unexpected" bit really does mean "unexpected"

[shs96c]

But we could add a new prompt handler of "leave in place"

[shs96c]

I'm getting married and in the final days before the wedding. I'm going to replying very slowly to this issue until I return to the UK.

[shs96c]

@jgraham's comment about needing to be aware that an alert would open and then interacting with it is correct (though, logically, no different from any other command --- you need to know what's happening to interact with things). I'm totally on-board with adding a "throw an exception, but leave it in place" option to the prompt handler table.

[andreastt]

Right, thanks for your explanation in #925 (comment). I now understand how it’s supposed to work.

But we could add a new prompt handler of "leave in place"

I think this is a good idea. And it’s pluggable into what we have currently.

I'm getting married and in the final days before the wedding. I'm going to replying very slowly to this issue until I return to the UK.

In totally off-topic way, that is great news! Congratulations! 🎆🍾