Open smit9234 opened 7 years ago
It's expected that the next command will fail if a modal dialog is open and has not been closed by that time. You will have to make sure that you are waiting long enough, which means until your AutoIt script has been finished and closed the dialog. The 100ms sleep you added here seem to be too less.
Hm, I actually had a look which command you execute and in this case it's findElement
. Checking the WebDriver spec I don't see that alert checks should be done at all for any of the element retrieval methods.
@andreastt, you added those checks via bug 1359004 a while ago. As it looks like it was a mistake to add them to those retrieval methods. Can you please have a look?
@whimboo That sounds like an omission from the specification. Filed https://github.com/w3c/webdriver/issues/1121.
Lets leave it open until the specification question has been solved.
I was able to get this to work by replacing the AutoIT script with the following
Alert alert = driver.switchTo().alert();
alert.sendKeys(username + Keys.TAB.toString()+password);
alert.accept();
Ah, nice workaround and good to know that we could even handle basic authentication that way. Thanks!
I would question if this would truly work for Basic Authentication from all browsers, if at all.
It works with Firefox because we can detect both types of dialogs at the moment.
Someone have a solution with using autoIt ?
@antho03 you should never use autoit if you really can avoid it. See above (https://github.com/mozilla/geckodriver/issues/977#issuecomment-336230380) for a possible solution.
@whimboo Ok thx for your answer, but can i use that with robotframework ? With command "Execute Javascript" ?
Sorry, but I don't know the robot framework, also is it off-topic here. Please get in contact with the support of that framework in how this can be done if unclear.
Hi,
I encountered the same issue and I am not sure if the following aspect has already been considered:
I close the basic auth dialog via Auto It, then sleep for a couple of seconds to be sure it is closed already, and after that, subsequent WebDriver calls like "driver.findElement"or "driver.getTitle()" throw an UnhandledAlertException.
This seems inappropriate given that is no alert present anymore at this point in time.
AutoIT and the Robot framework are completely off topic for this issue.
@mgehmayr-micro-focus you are not saying which version of Firefox and geckodriver you are using. What you might want is https://bugzilla.mozilla.org/show_bug.cgi?id=1416284 but that is only available in Firefox 59. @andreastt, maybe we should consider an uplift of this patch to 58?
@whimboo I initially used Firefox 57. Now I tried 59.0a1 (on Windows) and encountered a complete behavioral change in Firefox 59.0a1:
When I navigate to a web page that is secured by basic auth no "Authentication Required" dialog is displayed anymore. Instead I immeditaely see the "not authorized" web page (i.e. the weg page I see with Firefox 57 when I click Cancel on the "Authentication Required" dialog)
I also noticed exactly the same behaviour when I do start Firefox manually (like a normal Firefox user does that does not use Geckodriver or Selenium at all). I used the public site https://the-internet.herokuapp.com for testing.
Use case A (possible issue):
Expected: The "Authentication Required" asks me for my credentials Actual: I see the "not authorized" page immeditaely
Use case B (correct)
Is this behavioral change intended in Firefox 59.0a1?
@whimboo I tried Firefox 59.0a1 on 2 different Windows 10 machines: Same result: No "Authentication Required" dialog is shown for https://the-internet.herokuapp.com/basic_auth
I tried Firefox 59.0a1 on macOs (High Sierra) and there the "Authentication Required" dialog is shown as expected. Here I also the plain Firefox app (no Geckodriver / Marionette involved)
I am well aware of the fact that my observerations are not related to Geckodriver but to Firefox itself and that they might be off-topic in this bug report. I am just posting this info here because I encountered this road block when trying to verify if https://bugzilla.mozilla.org/show_bug.cgi?id=1416284 solves my AutoIt use case.
@whimboo I tried Firefox 59.0a1 with Geckodriver 19.1 on macOS.
This was my Selenium Test: I navigate to a basic auth web site and then manually log in (in my CI tests I use AutoIt for that). After that I get a NoAlertPresentException.
driver.navigate().to("https://the-internet.herokuapp.com/basic_auth");
Thread.sleep(20 * 1000); // sleep for 20 sec: in this time I manually enter the credentials (admin and admin)
driver.getTitle(); // fails with NoAlertPresentException
Geckodriver trace log is attached trace.log
Please note that the fix https://bugzilla.mozilla.org/show_bug.cgi?id=1416284 appears to work correctly: When I do not enter the credentials manually and just wait the 20 seconds I get an UnhandledAlertException and the basic auth dialog gets dismissed as expected with this fix.
I cannot reproduce the problem with the Basic Auth on Windows 10. I always get the dialog displayed whether which version I'm using. So I assume something is broken on your local system. Maybe file a bug directly for Firefox on Bugzilla.
I cannot reproduce the problem with Basic Auth on Windows 10 anymore with Firefox Nightly from 2018-01-07
A similar issue happens with latest version of WebDriver (3.14) and Gekodriver from a nuget package (Selenium.WebDriver.GeckoDriver.Win64 v0.22.0) published on 17th of September.
It seems like Gekodriver keeps an internal state about a modal being open. I base that on the fact that i'm closing the modal with AutoIt and any action i perform in the homepage as authenticated user, yields NoAlertPresentException. This is my conclusion hearing cases that this goes away if you close the alert with Accept(). In my case checking if the alert is present prior to the action throwing the exception confirms the fact that the alert is not there. AutoIt is offtopic I agree, but having geckodriver unaware of an alert being close (no matter by what means (external to webdriver let's say)) (such as the one for AD login) that Firefox opens when opening such page (AD Login) i think represents an issue.
@whimboo: I think your comment on bug 1359004, regarding alert checks being performed during find elements is spot on and can be the trigger of the issue if geckodriver has some kind of internal state related to AD login alert which gets out of sync (stale) when you close it manually or with something like autoit.
I'm experiencing this exception after passing the AD authorization and after having home page being successfully loaded. The NoAlertPresentException is thrown when accessing TagName property on a page element.
_OpenQA.Selenium.NoAlertPresentException: No modal dialog is currently open
at OpenQA.Selenium.Remote.RemoteWebDriver.UnpackAndThrowOnError(Response errorResponse)
at OpenQA.Selenium.Remote.RemoteWebDriver.Execute(String driverCommandToExecute, Dictionary2 parameters) at OpenQA.Selenium.Remote.RemoteWebElement.Execute(String commandToExecute, Dictionary
2 parameters)
at OpenQA.Selenium.Remote.RemoteWebElement.getTagName()
It's likely that there are some alert checks for actions like retrieving TagName for an element and geckodriver wrongfully believing there is an alert open. It can get that wrong impression(repeating myself) if it would keep track of alerts open / closed only via its api method calls and not inspecting the actual browser session / dom etc.
You cannot use any other tool beside geckodriver/Marionette at the moment to close those alerts. You would always face this above described problem. It will work once https://bugzilla.mozilla.org/show_bug.cgi?id=1477977 got fixed.
Please note that for authentication dialogs you can see a string like the following to the alert, which will enter both the user and password: "user" + Keys.TAB + "password"
. Then accept the alert.
System
For this application you must login using Windows Authentication, a Windows Authentication dialog appears before you can enter the site, AutoIT script is used to enter the user name and password. The test works until you go to click on a button, then fails due to an UnhandledAlertException.
See below for detailed info.
Testcase
Driver Capabilities
Stacktrace
Trace-level log