How to use afterAlertAccept method of org.openqa.selenium.support.events.AbstractWebDriverEventListener class

It looks like this site can detect Selenium and do not open with it.

You can hide it using Chrome Options. Try adding arguments like this before openning the url:

ChromeOptions options = new ChromeOptions();
options.addArguments("disable-blink-features=AutomationControlled");
ChromeDriver driver = new ChromeDriver(options);

Hope this helped, good luck!

Possible causes:

You are giving localhost as IP, ensure to match it with the IP on which appium started including port.

You are running test on an Emulator with android version lower than 4.2

PhantomJS uses different mechanism in setting capabilities

static ArrayList<String> cliArgsCap = new ArrayList<String>();
capabilities = DesiredCapabilities.phantomjs();
cliArgsCap.add("--web-security=false");
cliArgsCap.add("--ssl-protocol=any");
cliArgsCap.add("--ignore-ssl-errors=true");
capabilities.setCapability("takesScreenshot", true);
capabilities.setCapability(
    PhantomJSDriverService.PHANTOMJS_CLI_ARGS, cliArgsCap);
capabilities.setCapability(
    PhantomJSDriverService.PHANTOMJS_GHOSTDRIVER_CLI_ARGS,
        new String[] { "--logLevel=2" });
this.driver = new PhantomJSDriver(capabilities);

For more information about its command line, you could reference http://phantomjs.org/api/command-line.html

It doesn't look like you're actually using the regex. It seems like maybe this is what you're trying to do?

Assert.assertTrue(driver.getTitle().matches("*TST-*[0-9]{5}"));

EDIT #1:

It also seems like your regex might not be quite right, try:

Assert.assertTrue(driver.getTitle().matches(".*TST-\\d{5}.*"));

Like mentioned in previous answer this is expected behavior.

The only work around to date is to driver.get("domain.com/404") page. But this doesn't always work due to SSO often protects domain.com/*

I have made a new feature request on the spec: https://github.com/w3c/webdriver/issues/1238

to make it so the 404 work-around can always work.

The webdriver spec https://w3c.github.io/webdriver/webdriver-spec.html#add-cookie forces the current browser session to be on the domain where you are adding the cookie to.

This makes tons of sense and I agree with it.

This unfortunately prevents 2 key use cases:

You want to re-use cookies from another webdriver session in a new session to avoid repeating the work it took to get the cookies. Such as having to repeat a login. Allow a webdriver pool to be shared amongst unrelated threads where each thread might have their own cookies. The only current work around is to attempt to force the webdriver to go to a 404 error page with something like: webdriver.get("http://the-cookie-domain.com/404adsfasdf"). This would cause the page to go to domain and would allow you to add cookies with addCookie. But this hardly ever works. Because the page is very often protected by SSO, any attempt to go to http://the-cookie-domain.com/* sends you to an SSO login page e.g. http://login.ssodomain.com and now you have the same problem.

We should add a new method to the spec webdriver.goTo404Page(domain) to allow this use-case. This method should simulate a 404 HTTP status code response from domain in the browser.

Alternatively maybe be a new overload to addCookie could allow this, for example: void addCookie(Cookie var1, String goTo404PageOfDomain);

By allowing users to go to a fake 404 page of any given domain, this guarantees the 404-page workaround works for any page and these 2 use cases are now possible.

For firefox, you can modify Marionette slightly to just remove this check.

diff --git a/testing/marionette/cookie.js b/testing/marionette/cookie.js
--- a/testing/marionette/cookie.js
+++ b/testing/marionette/cookie.js
@@ -144,14 +144,14 @@ cookie.add = function(newCookie, {restri
     newCookie.domain = "." + newCookie.domain;
   }

-  if (restrictToHost) {
-    if (!restrictToHost.endsWith(newCookie.domain) &&
-        ("." + restrictToHost) !== newCookie.domain &&
-        restrictToHost !== newCookie.domain) {
-      throw new InvalidCookieDomainError(`Cookies may only be set ` +
-          `for the current domain (${restrictToHost})`);
-    }
-  }
+//  if (restrictToHost) {
+//    if (!restrictToHost.endsWith(newCookie.domain) &&
+//        ("." + restrictToHost) !== newCookie.domain &&
+//       restrictToHost !== newCookie.domain) {
+//      throw new InvalidCookieDomainError(`Cookies may only be set ` +
+//          `for the current domain (${restrictToHost})`);
+//    }
+//  }

   // remove port from domain, if present.
   // unfortunately this catches IPv6 addresses by mistake
diff --git a/testing/marionette/driver.js b/testing/marionette/driver.js
--- a/testing/marionette/driver.js
+++ b/testing/marionette/driver.js
@@ -2638,9 +2638,9 @@ GeckoDriver.prototype.addCookie = functi
   let {protocol, hostname} = this.currentURL;

   const networkSchemes = ["ftp:", "http:", "https:"];
-  if (!networkSchemes.includes(protocol)) {
-    throw new InvalidCookieDomainError("Document is cookie-averse");
-  }
+//  if (!networkSchemes.includes(protocol)) {
+//    throw new InvalidCookieDomainError("Document is cookie-averse");
+//  }

   let newCookie = cookie.fromJSON(cmd.parameters.cookie);

diff --git a/testing/marionette/test_cookie.js b/testing/marionette/test_cookie.js
--- a/testing/marionette/test_cookie.js
+++ b/testing/marionette/test_cookie.js
@@ -190,10 +190,10 @@ add_test(function test_add() {
   });
   equal(2, cookie.manager.cookies.length);

-  Assert.throws(() => {
-    let biscuit = {name: "name3", value: "value3", domain: "domain3"};
-    cookie.add(biscuit, {restrictToHost: "other domain"});
-  }, /Cookies may only be set for the current domain/);
+//  Assert.throws(() => {
+//    let biscuit = {name: "name3", value: "value3", domain: "domain3"};
+//    cookie.add(biscuit, {restrictToHost: "other domain"});
+//  }, /Cookies may only be set for the current domain/);

   cookie.add({
     name: "name4",

You can use JavaScriptExecutor for scrolling.

Scroll Down

((JavascriptExecutor)driver).executeScript("window.scrollTo(0,document.body.scr‌​ollHeight);");

Scroll Up

((JavascriptExecutor)driver).executeScript("window.scrollTo(0,0);");

Check the below links:

• Implicit Wait - It instructs the web driver to wait for some time by poll the DOM. Once you declared implicit wait it will be available for the entire life of web driver instance. By default the value will be 0. If you set a longer default, then the behavior will poll the DOM on a periodic basis depending on the browser/driver implementation.

• Explicit Wait + ExpectedConditions - It is the custom one. It will be used if we want the execution to wait for some time until some condition achieved.

Every time the DOM is changed, or even just refreshed, all previously located elements become stale and are no longer valid. It doesn't matter if the element looks identical, its a new element.

Java ExpectedConditions (and only Java currently) have the refreshed to wait for the element to be redrawn in the DOM

(new WebDriverWait(driver, 30)).until(ExpectedConditions.refreshed(ExpectedConditions.visibilityOf(successMsg)));

You can only wait on an object if you've acquired the lock for it using synchronized.

I don't know whether you're meant to use wait using WebDriver - if you are, you'd need something like:

synchronized (driver)
{
    driver.wait();
}

However, if you're waiting for something to occur, it's more likely that there's an alternative method you're meant to be using. Perhaps WebDriverWait?