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

Thanks, answers inline.

On Tue, Jun 30, 2015 at 7:00 AM, David Burns <dburns@mozilla.com> wrote:

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

Filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=28968 for that.


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

I found an existing related bug and added
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24816#c3 there. That covers
unexpectedAlertBehavior capability and "Alert thrown from onbeforeunload
 event".

Thanks,
Seva

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