Re: [14.1.4 sendKeys()]: Question about unexpected alert

I have a few suggestions related to this. Happy to file separate bugs or
PRs for these; let me know if any of this makes sense and what I should do.

1. Paragraph that John quoted, along with the one just before that, should
go in their own section (they are unrelated to sendKeys()). It would help
if the spec defined what it calls the "unexpected modal dialog", too.

2. In the paragraph that John quoted it is unclear what exactly is meant by
"The default for this should be dismiss". It can either be "default
behavior if user didn't specify anything special at all" or "default
behavior if user did specify via a capability that they would like the
unexpected modal dialogs to be closed but didn't specify whether they
should be dismissed or accepted".
I suggest replacing "The default for this should be dismiss" by (something
like):

"By default all unexpected model dialogs MUST result in Unexpected alert
open error being thrown. User SHOULD be able to request the remote end to
automatically close unexpected modal dialogs. The way user requests that is
by requesting 'unexpectedAlertBehaviour' capability with value 'dismiss' or
'accept'. Not requesting 'unexpectedAlertBehaviour' capability is
equivalent to requesting it with the default value of 'throw'."

(Yes, I suggest the spec should be specific about the name of the
capability, its values and behavior, even if supporting that capability at
all is only a SHOULD. unexpectedAlertBehaviour is the capability that's
supported by FirefoxDriver [and only FirefoxDriver?] right now.)

3. Alert thrown from onbeforeunload event (and a result of a navigation
command or quit() or close() or any other command) MUST still throw by
default (e.g. unless 'unexpectedAlertBehaviour' capability is specified
with either "dismiss" or "accept").

Seva

On Wed, Jun 24, 2015 at 1:36 PM, Luke Inman-Semerau <luke.semerau@gmail.com>
wrote:

> Yes, your statement is correct and I think to the intention of the
> spec. Wording is hard :)  The spec is also meaning to convey that when
> the Unexpected alert error gets raised, the Remote End also dismisses
> the dialog (and it's configurable whether that be a "dismiss" or an
> "accept" in the case of a window.prompt() or window.confirm()....
> although I would think there's an edge case here regarding prompt and
> an auto 'accept' with a blank value would cause javascript to
> re-prompt).
>
>
> On Wed, Jun 24, 2015 at 12:56 PM, John Jansen <John.Jansen@microsoft.com>
> wrote:
> > In the spec[1] it says,
> > "The remote end SHOULD have a mechanism to allow unexpected modal
> dialogs to be closed to prevent the remote end from becoming unusable. The
> default for this should be dismiss. The local end SHOULD allow a capability
> to be set that allows the default value to be overridden with accept. The
> local end SHOULD also allow setting the default behaviour to wait for a
> command to handle the modal. If the next command does not interact with the
> modal it MUST return a Unexpected alert open error to the local end."
> >
> > It is not clear how webdriver is supposed to know that the dialog is
> unexpected and then retain state so that the next action (that was meant to
> happen to the page, but actually happened to the modal dialog) is supposed
> to be stored.
> >
> > Current behavior for ChromeDriver seems to be that the test just times
> out. Since the modal is unexpected, the test fails, and the test author
> then needs to update the test. I expect most test authors have an
> 'unexpected alert open' exception handler in their code. Is this meant to
> replace that?
> >
> > I believe the design should be something like this:
> > "If a modal dialog is shown and the next command does not interact with
> the modal the remote end MUST return an Unexpected alert open error to the
> local end."
> >
> > And then we just let individuals deal with it how they want to, rather
> than add the complexity to the driver itself.
> >
> > Thoughts?
> >
> > Thanks!
> > -John
> >
> > [1] https://w3c.github.io/webdriver/webdriver-spec.html#sendkeys-1
> >
>
>