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

Comments inline

David

On 29 June 2015 at 23:23, Seva Lo <vlotoshnikov@gmail.com> wrote:

> 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.
>

Don't do PRs yet for sendKeys. Raise bugs as that area needs to be
rewritten from scratch.



>
> 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.
>

Agreed. We probably could handle this in the main way that we handle
requests (
http://w3c.github.io/webdriver/webdriver-spec.html#processing-model). Feel
free to submit a PR for that since most commands would hit this.


>
> 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'."
>

This looks useful. Just need to think of a good place to put it in the
spec.

>
> (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.)
>

Is this a capability that we want to have moving forward? I have never felt
the need to use it but people who scrape the web using it like it. Two
separate use cases which make me wonder if we should add it in.


>
> 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").
>

Yea, we need to handle this in the spec too.


>
> 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
>> >
>>
>>
>