Status of support for alert, confirm and prompt

[Marc Guillemot]

Hi,

what is the status of the support for alert, confirm and prompt and what
are the plans in this area?

Looking at the source code I can see the Alert class that seems to be
done to handle alert and confirm, but not prompt. I've found as well an
implementation of Alert for the FirefoxDriver but it is not reachable
without reflection.
There is AlertsTest but the tests are @Ignore (btw: I don't see why a
reading access should throw as expected in
testShouldThrowAnExceptionIfAnAlertHasNotBeenDealtWith).

I would probably be able to quickly contribute an implementation for the
HtmlUnitDriver if the interfaces and expectations are cleanly defined.

Cheers,
Marc.

[Simon Stewart]

Hi Marc,

We've started implementing those tests for Firefox, and I run them on
my local machine. They're not stable yet, which is why they're not
enabled for the default builds.

The reason why the Alert subclass is not reachable other than via
reflection is that the only way to access it is via the "switchTo()"
method:

switchTo().alert();

We've not exposed this method because nothing implements it yet ---
since you may be doing that for the HtmlUnitDriver, I can make the
change :)

The way that I expect alerts to work in webdriver is that a user
should "switchTo()" an alert when it happens (because they expect an
alert to occur in their tests --- we're very deliberately not
supporting the use case of "I don't know if an alert is open or not")
If an alert opens that the user does not switch to, it indicates that
an unexpected condition has occurred, so if the next command to
webdriver doesn't deal with the alert we throw an
"UnhandledAlertException" and dismiss the open alert.

The reason for dismissing the alert is because the common usage of
webdriver is to re-use a browser instance for many tests. By throwing
the alert, we've probably just caused a test to fail, which means that
another test is about to start. If the alert is still present, we'd
end up failing that too.

Regards,

Simon

> --
>
> You received this message because you are subscribed to the Google Groups "webdriver" group.
> To post to this group, send email to webd...@googlegroups.com.
> To unsubscribe from this group, send email to webdriver+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/webdriver?hl=en.
>
>
>

[Marc Guillemot]

Hi Simon,

thanks for the explanation. Access with switchTo() makes sense to me as
well as UnhandledAlertException/NoAlertPresentException.

I have nevertheless a two questions:

1) what about handling prompt?

2) why read only operations should be forbidden (as expected by
testShouldThrowAnExceptionIfAnAlertHasNotBeenDealtWith)?
I can imagine that it may make sense for a test to "see" the page's
state before the alert is clicked as this is the page state a "normal"
user would see.

3) In which cases is (should) an alert silently be dismissed in the
FirefoxDriver?

Cheers,
Marc.

Simon Stewart a �crit :

[PerfectStorm]

We we also be able to retrieve the text out?

> > On Tue, Dec 1, 2009 at 7:23 PM, Marc Guillemot <mguille...@yahoo.fr> wrote:
> >> Hi,
>
> >> what is the status of the support for alert, confirm and prompt and what
> >> are the plans in this area?
>
> >> Looking at the source code I can see the Alert class that seems to be
> >> done to handle alert and confirm, but not prompt. I've found as well an
> >> implementation of Alert for the FirefoxDriver but it is not reachable
> >> without reflection.
> >> There is AlertsTest but the tests are @Ignore (btw: I don't see why a
> >> reading access should throw as expected in
> >> testShouldThrowAnExceptionIfAnAlertHasNotBeenDealtWith).
>
> >> I would probably be able to quickly contribute an implementation for the
> >> HtmlUnitDriver if the interfaces and expectations are cleanly defined.
>
> >> Cheers,
> >> Marc.
>
> >> --
>
> >> You received this message because you are subscribed to the Google Groups "webdriver" group.
> >> To post to this group, send email to webd...@googlegroups.com.
> >> To unsubscribe from this group, send email to webdriver+...@googlegroups.com.

> >> For more options, visit this group athttp://groups.google.com/group/webdriver?hl=en.

>
> > --
>
> > You received this message because you are subscribed to the Google Groups "webdriver" group.
> > To post to this group, send email to webd...@googlegroups.com.
> > To unsubscribe from this group, send email to webdriver+...@googlegroups.com.

> > For more options, visit this group athttp://groups.google.com/group/webdriver?hl=en.- Hide quoted text -
>
> - Show quoted text -

[Marc Guillemot]

Simon, any answer to these questions?

Cheers,
Marc.

Marc Guillemot a �crit :

[Simon Stewart]

Sorry: not been keeping up to date with my email. *sigh* Here we go:

* prompt and confirm will be handled the same way.

* Read only operations are forbidden because it involves interacting
with the JS thread on the DOM, which is blocked by the alert. Touching
it will cause the firefox driver to hang.

* We plan on silently dismissing the common problematic dialogs:
script running too long, bad SSL certs, "your browser has crashed, do
you want to send data to X" and so on. Download dialogs are a
different thing entirely. I have no idea how we can handle those
cleanly, though I suspect we may force all downloads to go to a single
location and provide a flag for users to check (an event listener is
also an idea, but incongruous with the rest of the API)

* There will be a "getText" method to find out what the alert's text was.

Cheers,

Simon

On Tue, Dec 8, 2009 at 10:45 AM, Marc Guillemot <mguil...@yahoo.fr> wrote:
> Simon, any answer to these questions?
>
> Cheers,
> Marc.
>

> Marc Guillemot a écrit :

>> Hi Simon,
>>
>> thanks for the explanation. Access with switchTo() makes sense to me as
>> well as UnhandledAlertException/NoAlertPresentException.
>>
>> I have nevertheless a two questions:
>>
>> 1) what about handling prompt?
>>
>> 2) why read only operations should be forbidden (as expected by
>> testShouldThrowAnExceptionIfAnAlertHasNotBeenDealtWith)?
>> I can imagine that it may make sense for a test to "see" the page's
>> state before the alert is clicked as this is the page state a "normal"
>> user would see.
>>
>> 3) In which cases is (should) an alert silently be dismissed in the
>> FirefoxDriver?
>>
>> Cheers,
>> Marc.
>>

>> Simon Stewart a écrit :

[Marc Guillemot]

Hi Simon,

> Sorry: not been keeping up to date with my email. *sigh* Here we go:
>
> * prompt and confirm will be handled the same way.

any mean to distinguish them?

Again: what about prompt?

>
> * Read only operations are forbidden because it involves interacting
> with the JS thread on the DOM, which is blocked by the alert. Touching
> it will cause the firefox driver to hang.

this means that an implementation detail of the FirefoxDriver leaks in
the design of the API :-(

Are you sure that you can correctly handle following situtation with the
Firefox driver in this case: call toggle() and return the right value
for a checkbox which has some handler that may change the checkbox state
and that triggers an alert.

> * We plan on silently dismissing the common problematic dialogs:
> script running too long, bad SSL certs, "your browser has crashed, do
> you want to send data to X" and so on. Download dialogs are a
> different thing entirely. I have no idea how we can handle those
> cleanly, though I suspect we may force all downloads to go to a single
> location and provide a flag for users to check (an event listener is
> also an idea, but incongruous with the rest of the API)

this was not my question. I was only talking about dialogs from JS alert
and JS confirm.

In which cases is (should) an alert silently be dismissed in the
FirefoxDriver?

Cheers,
Marc.

> * There will be a "getText" method to find out what the alert's text was.

you mean when it is automatically dismissed?

Cheers,
Marc.

[Simon Stewart]

Answers inline.

On Tue, Dec 8, 2009 at 3:03 PM, Marc Guillemot <mguil...@yahoo.fr> wrote:
> Hi Simon,
>
>
>> Sorry: not been keeping up to date with my email. *sigh* Here we go:
>>
>> * prompt and confirm will be handled the same way.
>
> any mean to distinguish them?

No. WebDriver isn't a general crawling API: you either know what kind
of alert you're dealing with or it's not meant to be there.

> Again: what about prompt?

As in "window.prompt"? As I said, it's handled as an "Alert", which
will have a "sendKeys" method on it so you can type whatever needs
typing.

>> * Read only operations are forbidden because it involves interacting
>> with the JS thread on the DOM, which is blocked by the alert. Touching
>> it will cause the firefox driver to hang.
>
> this means that an implementation detail of the FirefoxDriver leaks in
> the design of the API :-(

The same is also true of IE and Chrome. It seems like a reasonable
trade-off between ultimate flexibility and actual "implementability".

> Are you sure that you can correctly handle following situtation with the
> Firefox driver in this case: call toggle() and return the right value
> for a checkbox which has some handler that may change the checkbox state
> and that triggers an alert.

Right now, the API doesn't handle this cleanly, so I know that we
can't. *sigh* It should be possible to try and grab the information
before allowing the alert to be displayed and return that to the user.

>> * We plan on silently dismissing the common problematic dialogs:
>> script running too long, bad SSL certs, "your browser has crashed, do
>> you want to send data to X" and so on. Download dialogs are a
>> different thing entirely. I have no idea how we can handle those
>> cleanly, though I suspect we may force all downloads to go to a single
>> location and provide a flag for users to check (an event listener is
>> also an idea, but incongruous with the rest of the API)
>
> this was not my question. I was only talking about dialogs from JS alert
> and JS confirm.

window.alert, window.prompt and window.confirm will all be handled by
the single "Alert" interface, in much the same way as "WebElement"
represents every possible HTML element.

> In which cases is (should) an alert silently be dismissed in the
> FirefoxDriver?

The rule of thumb: an alert will be dismissed if a user doesn't
"switchTo()" it and performs another action. An alert can also be
dismissed by a user. The interface will probably end up looking like:

public interface Alert {
// Get the message of the alert
String getText();

// Fill in a prompt
void sendKeys(CharSequence... keys);

// Click "OK"
void accept();

// Click "cancel"
void dismiss();
}

Cheers,

Simon

> Cheers,
> Marc.
>
>> * There will be a "getText" method to find out what the alert's text was.
>
> you mean when it is automatically dismissed?
>
> Cheers,
> Marc.
>

[Jason]

Should the interface be called Alert? That implies a very specific
type of modal dialog. I don't think it's necessary to have [Alert|
Prompt|Confirm] extends ModalDialog, but it is at least worth mulling
over...

On Dec 8, 7:46 am, Simon Stewart <simon.m.stew...@gmail.com> wrote:
> Answers inline.
>

[Simon Stewart]

I just listened to what people called the modal dialogs that pop up as
they try and get their work done and picked that as the name of the
interface. I can see how it might be a little confusing. ModalDialog
doesn't have quite the same immediacy, though.

I tend to think that having four interfaces for these is possibly
being a little too fine-grained, given the wide-ranging remit of the
WebElement interface.

Simon

[Marc Guillemot]

Thanks for the response. I don't share all your points, but this clearly
explains what you want to do.

Cheers,
Marc.

Simon Stewart a �crit :

[Steve CCRP]

Just wondering if the changes made as part of adding support for alert/
confirm/prompt will also allow window.showModalDialog to work

Currently, WebDriver blocks when opening up a modal dialog. When/If
fixed, Will the modal dialog be part of the window handles and you can
then switch to the modal dialog? Or just switched automatically since
it is now the only window you can interact with?

Example page with window.showModalDialog:
https://developer.mozilla.org/samples/domref/showModalDialog.html

Code (that doesn't work yet...):
driver.get("http://developer.mozilla.org/samples/domref/
showModalDialog.html");
driver.findElement(By.xpath("//input")).click();
// blocked until the modal dialog is closed. Printout below doesn't
display
System.out.println("done");

On Dec 9, 1:38 am, Marc Guillemot <mguille...@yahoo.fr> wrote:
> Thanks for the response. I don't share all your points, but this clearly
> explains what you want to do.
>
> Cheers,
> Marc.
>
> Simon Stewart a crit :
>
> > Answers inline.
>

[Simon Stewart]

Hi Steve,

Right now none of the work will support the "showModalDialog" Can you
please open a new issue for this?

Regards,

Simon