How to use TracedHttpClient class of org.openqa.selenium.remote.tracing package

You can start the selenium server yourself instead of using rsDriver

browserP <- "C:/Users/john/Desktop/Tor Browser/Browser/firefox.exe"
jArg <- paste0("-Dwebdriver.firefox.bin=\"", browserP, "\"")
pLoc <- "C:/Users/john/Desktop/Tor Browser/Browser/TorBrowser/Data/Browser/profile.meek-http-helper/"
jArg <- c(jArg, paste0("-Dwebdriver.firefox.profile=\"", pLoc, "\""))

wdman::selenium(jvmargs=jArg, selargs='any selenium args')
remDr <- remoteDriver(browserName ="firefox", port=4567L)
driver <- remDr$open()

Webdriver has no built in mechanism for adding a personal cert.

If you are using firefox the only way that I have found to do this is to create a firefox profile and add the certificate to it. You can then either reuse the profile when you run your tests OR, and this is my prefered option, take the cert8.db and key3.db files and add them to the profile that webdriver creates at runtime.

I am not sure how yo do this in java, but in ruby I override the layout_on_disk method of FirefoxProfile to add the extra files I required. Java has the same class so you should be able to do this same thing.

Sauce Labs != Selenium

Sauce labs use that capability to provision you a VM with the desired resolution, it's not a capability that Selenium itself knows about.

Selenium is not capable of modifying your desktop resolution!

If you want to modify your browser size in Selenium so that it matches a specific resolution you can do a:

driver.manage().window().setSize(new Dimension(1024, 768))

The above is not supported with Opera driver, so instead you would need to do:

DesiredCapabilities capabilities = DesiredCapabilities.opera()
capabilities.setCapability("opera.arguments", "-screenwidth 1024 -screenheight 768")

While setting the browser size is not the same as setting the screen resolution, it should for all intents and purposes meet your requirements.

You can also check pageloaded using following code

IWait<IWebDriver> wait = new OpenQA.Selenium.Support.UI.WebDriverWait(driver, TimeSpan.FromSeconds(30.00));

 wait.Until(driver1 => ((IJavaScriptExecutor)driver).ExecuteScript("return document.readyState").Equals("complete"));

elementToBeClickable is used for checking an element is visible and enabled such that you can click it.

ExpectedConditions.elementToBeClickable returns WebElement if expected condition is true otherwise it will throw TimeoutException, It never returns null.

So if your using ExpectedConditions.elementToBeClickable to find an element which will always gives you the clickable element, so no need to check for null condition, you should try as below :-

WebDriverWait wait = new WebDriverWait(Scenario1Test.driver, 10); 
WebElement element = wait.until(ExpectedConditions.elementToBeClickable(By.xpath("(//div[@id='brandSlider']/div[1]/div/div/div/img)[50]")));
element.click();

As you are saying element.click() passes both on link and label that's doesn't mean element is not clickable, it means returned element clicked but may be there is no event performs on element by click action.

Note:- I'm suggesting you always try first to find elements by id, name, className and other locator. if you faced some difficulty to find then use cssSelector and always give last priority to xpath locator because it is slower than other locator to locate an element.

Hope it helps you..:)

They are not the same.

appDriver.findElement(By.xpath("//UIATableCell[2]")).findElement(By.xpath("//UIAStaticText[4]"));

Here, you are searching for //UIAStaticText[4] anywhere, at any level in the entire DOM tree:

When using xpath be aware that webdriver follows standard conventions: a search prefixed with "//" will search the entire document, not just the children of this current node. Use ".//" to limit your search to the children of this WebElement.

While //UIATableCell[2]/UIAStaticText[4] would search among the direct children of //UIATableCell[2] only.

The key thing here is the resolution, you must ensure that resolution is the same for base "golden" images and those you capture during test.

1. Set size of the browser window to fixed size, eg. (1920x1080),
2. Make all screenshots in this resolution,
3. During the test: before each image-comparison check if the window size is (1920x1080) if not I change it temporarily,
4. Take screenshot,
5. Compare image with original "golden" img
6. Do window maximize

Other solution is to capture screenshots of single WebElement rather than whole page, because WebElements often are resolution independent.

Try this code. I tried on Chrome 54 with webdriver 2.53 on windows 8. Do not touch the mouse during test or even better move the cursor out of screen range when test starts.

   WebElement elem = driver.findElement(By.className("ytp-progress-bar"));

    int width = elem.getSize().getWidth();

    Actions act = new Actions(driver);
    act.moveToElement(elem).moveByOffset((width/2)-2, 0).click().perform();

You can figure out the offset from the many attributes in the div 'ytp-progress-bar'. You do not need to find width etc.

You have to move to the progress bar initially because it disappears after 2-3 secs due to inactivity on the video screen.

Webdriver utilizes a browser's native support for mapping the DOM element to WebElement object using id/xpath etc.

The JavascriptExecutor.executeScript executes an external script in the context of the currently selected browser window. (similar to an augmented browsing tool like grease monkey, if you ever used), and in case the script returns any DOM element its converted into WebElement object.

One can also say, the click simulated by WebDriver on a browser is similar to what actual user do as compared to one invoked using javascript.

In reality, with WebDriver not all the events can be automated flawlessly with all the web browsers, in fact with different versions of the same Web browser also. (i.e. different version of IE, FF etc behave differently). Still WebDriver is the near best tool available for this.

Once (~4 years back) on a certain version of IE we observed that we can't send right click or may be hover mouse on generated menu links, so we used js to simulate that, which performed very much browser independent way. so you can now conclude what executing external javascript can be good for.

Also, there are automated web testing frameworks which use javascript for everything instead of browser's native support. e.g. :http://en.wikipedia.org/wiki/Sahi_%28software%29

Ref:

• #executeScript%28java.lang.String,%20java.lang.Object...%29
• #findElement%28org.openqa.selenium.By%29