User prompt handler capabilities

[jgraham]

---

Preview | Diff

[OrKoN]

cc @nechaev-chromium

[whimboo]

I assume that we can move this up given that it doesn't depend on any user prompt handler setting.

[jgraham]

I don't follow? If type is beforeUnload and you have beforeUnload in handlers the previous step applies. That's important for BiDi where we don't totally override the beforeUnload handler, but still default to dismissing it if you didn't add it in capabilities.

[whimboo]

Ah good point. Would it make sense to add a note here which explains why it needs to stay here?

[jgraham]

I added this to the note above.

[whimboo]

Thanks @jgraham! That looks fine to me now.

@sadym-chromium and maybe @gsnedders could you review as well please?

[css-meeting-bot]

The Browser Testing and Tools Working Group just discussed User prompt handlers.

The full IRC log of that discussion

<AutomatedTester> topic: User prompt handlers
<AutomatedTester> github: https://github.com//pull/1791
<jgraham> I note that is a position on whether Invalid Argument is only for things that can be detected from the schema; if we reject files for not existing then it isn't. So if we want that property we should invent a new error.
<AutomatedTester> jgraham (IRC): after working through handlers for user prompts in classic which shoulnd't change how we do things
<AutomatedTester> ... and now have something up for bidi
<AutomatedTester> ... in bidi we want to be notified before unload where in classic it was automatically handled
<AutomatedTester> ... whimboo has looked at this and since it's a new feature it would be good if other vendors can have a look
<AutomatedTester> ... one of the future items is that we can have the file dialog is handled this way
<AutomatedTester> ... as well as the classic PR there are also draft PRs on HTML and WebDriver Bidi
<AutomatedTester_> q?

[OrKoN]

Could you please add a short summary about the implications of the change? it's not expected to affect the current WebDriver Classic behavior, right?

[jgraham]

This is specifically worded to not change classic behaviour at all, at least in a mandatory way.

The new feature in the PR is the ability to define per-prompt-type behaviour e.g.

userPromptHandler: {
  alert: "accept",
  confirm: "cancel",
  prompt: "ignore"
}

That's not terribly useful just for classic as is, but it's more useful for BiDi to be able to do things like:

userPromptHandler: {
  beforeUnload: "ignore",
  default: "accept"
}

Which would mean that you get an event and have to explicitly handle beforeUnload prompts, but other kinds of prompts are auto-accepted. It's also likely to be useful in the future for file-type prompts which are rather likely to have different behaviour from other prompt types.

[OrKoN]

LGTM

[whimboo]

userPromptHandler: {
alert: "accept",
confirm: "cancel",
prompt: "ignore"
}

It was actually not intended to add a new capability with the name userPromptHandler. Instead it should look like:

unhandledPromptBehavior: {
  alert: "accept",
  confirm: "cancel",
  prompt: "ignore"
}

With a future use of:

unhandledPromptBehavior: {
  beforeUnload: "ignore",
  default: "accept"
}

I created PR #1808 to get this fixed.