w3c / webdriver

Remote control interface that enables introspection and control of user agents.
https://w3c.github.io/webdriver/
Other
679 stars 194 forks source link

User prompt handler capabilities #1791

Closed jgraham closed 6 months ago

jgraham commented 7 months ago

Preview | Diff

css-meeting-bot commented 6 months ago

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/w3c/webdriver/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 commented 6 months ago

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 commented 6 months ago

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.

whimboo commented 5 months ago

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.