In a test case, I need to enter a file path in the Windows dialog box which in turn uploads the file in the specific location. I used Robot class to handle this.

Issue: It works seamlessly in local machine, but when I run the same script in a remote machine the file path is being typed/printed where the cursor is located in the local machine.

My code is below:

import java.awt.Robot;
import java.awt.Toolkit;
import java.awt.datatransfer.StringSelection;
import java.net.URL;
import org.openqa.selenium.By;
import org.openqa.selenium.Platform;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.chrome.ChromeDriver;
import org.openqa.selenium.remote.DesiredCapabilities;
import org.openqa.selenium.remote.RemoteWebDriver;

public class Remote {

    public static void main(String [] args) throws Exception{

         String huburl="<hub url>";
                DesiredCapabilities capabilities = DesiredCapabilities.chrome();

            capabilities.setCapability("name", "Remote File Upload using Selenium 2's FileDetectors");
           WebDriver driver=new RemoteWebDriver(new URL(huburl),capabilities);

            driver.get("application url");

            String liId = driver.findElement(By.partialLinkText("PPl (qa9)")).findElement(By.xpath("..")).getAttribute("id");
            driver.findElement(By.partialLinkText("PPl (qa9)")).findElement(By.xpath("..")).click();
            driver.switchTo().frame(liId + "-Frame");

            String importpath=  System.getProperty("user.dir").concat("\\src\\test\\resources\\testData\\addEntityOrg.ini");

            StringSelection sel =new StringSelection(importpath);


           Robot robo=new Robot();


  • Make sure that your remote machine screen size is same as your machine. Also, post your Robot class code here. It will help us give you more inputs.
    – Mayur
    Commented Mar 1, 2017 at 9:11

2 Answers 2


Issue: It works seamlessly in local machine, but when I run the same script in a remote machine the file path is being typed/printed where the cursor is located in the local machine.

The problem is that the test is NOT executed from the remote machine, but from your local machine by changing the huburl to point to the remote machine. This way you are working with the browser on a remote computer, but the Robot instance is binded to the machine from which was started and that's why you're receiving it's actions on your local machine.

If the test is started from the remote machine it should work.


When you start the execution on a remote machine, it is literally that - a different machine, which has no knowledge or access to the files on your local - it has its own filesystem, and your script tells it "set the filename to the local hard disk, the user directory concatenated with this subpath".

I see you're using a hub, so - presumably - this is an on-prem environment on which you have control.

So here are three solutions, from the least preferable, to the most.

Option 1 - local copies

I see you're using a system var user.dir - copy the files to it, and they will resolve. On every hub node. You are in for a lot of copying. When the system user used for starting the hub node changes - you are in for a lot of copying. When a file is changed, or a new one is added to the dataset - well, you get my point.

Pros - well, it's a solution. Cons - pretty much, everything.

Option 2 - shared location

With the presumption access is available to the hub, create a network share, mount it on all hub machines with the same uri - for example \\auto-shares, and use it as the base in the script.

Pros -

  • one-time setup (don't forget to do it for new nodes);
  • presumably fast transfer speed;
  • no extra changes for the test harness system (see option 3).

Cons -

  • access required;
  • doesn'the scale optimally;
  • can't be used for cloud hubs (cons #1)

Option 3 - download the needed files

This one might seem tricky at first, but in general is the most robust. In summary, before starting the test, download the needed files from a know internet location, to user.dir - thus the tests will always find it. This is best done on run initialization/setup level - if it fails, no need to run the tests.

The location can be anything you can get your hands on (and control) - a test http server accessible from outside, the corp site :), or even a file sharing service (generally, not a good idea...)

Pros -

  • applicable to practically everything;
  • can be used for cloud hubs (browserstack for sure allows saving files locally during a run);
  • set-and-forget (in theory :) - there's always maintenance involved).

Cons -

  • requires well-thought out changes to the test harness/framework;
  • if you'll be downloading the files by the browser (and you should, so this works in cloud hubs), they have to be started with profiles for automatic file download and overwriting;
  • security- and I cannot stress this high enough - the files should not contain and secret/private/proprietary information, as they are publicly accessible by definition.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.