1

I have following situation. once I start a Selenium test, a browser window will be opened. Since I have a bunch of tests and I start them many times every day, I would not let Selenium to open the new browser window on the front of my current browser(where I am working), but on the background, so it wouldn't disturb me. Is it possible?

PS to clarify why I need this - many times in a day, when I working in the current browser and the selenium tests are running, browser windows from Selenium for every test opens just suddenly and I can suddenly close it, type something, etc.

What I have now:

img

Cœur
  • 37,241
  • 25
  • 195
  • 267
Andrei Suvorkov
  • 5,559
  • 5
  • 22
  • 48
  • 1
    Your use case is still not clear to me. – cruisepandey Sep 04 '18 at 09:31
  • @cruisepandey I want to run tests so, that Selenium browser window opens not on the front of my browser window, but somehow in the background – Andrei Suvorkov Sep 04 '18 at 09:33
  • 1
    As workaround try something like `driver.manage().window().setPosition(newPoint(0, 2000));` (not sure about Java syntax correctness). Also check [this](https://stackoverflow.com/questions/16180428/can-selenium-webdriver-open-browser-windows-silently-in-background) – Andersson Sep 04 '18 at 09:40
  • 1
    IMO, it is not possible. Because when you do it manually , new browser windows opens in a front of current window. Though you can launch a re sizable chrome, But I see that is not your use case. – cruisepandey Sep 04 '18 at 09:41
  • It is not a problem, you can use @Andersson solution – iamsankalp89 Sep 04 '18 at 10:14
  • @Andersson `driver.manage().window().setPosition(newPoint(0, 2000));` that is better than now, but still window opens in front of all windows opened before and only then disappears. Thank you for the link. I think I will use `--headless` mode, even it is not exactly what I want. Thank you very much! – Andrei Suvorkov Sep 04 '18 at 10:33

2 Answers2

3

To start with Software Test Automation is an art. Your test bed should be:

  • Configured with all the required softwares, libraries and binaries.
  • Test Execution must be performed in a controlled environment for optimized performance.
  • While your @Tests are executing, it should be free from Manual Intervention.

  • Particularly when your @Tests are Selenium based, while test execution is In Progress the Test Environment shouldn't be intervened because:

    • At the lowest level, the behavior of actions class is intended to mimic the remote end's behavior with an actual input device as closely as possible, and the implementation strategy may involve e.g. injecting synthesized events into a browser event loop. Therefore the steps to dispatch an action will inevitably end up in implementation-specific territory. However there are certain content observable effects that must be consistent across implementations. To accommodate this, the specification requires that remote ends perform implementation-specific action dispatch steps, along with a list of events and their properties. This list is not comprehensive; in particular the default action of the input source may cause additional events to be generated depending on the implementation and the state of the browser (e.g. input events relating to key actions when the focus is on an editable element, scroll events, etc.).

  • Additionally,

    • An activation trigger generated by the WebDriver API user needs to be indistinguishable from those generated by a real user interacting with the browser. In particular, the dispatched events will have the isTrusted attribute set to true. The most robust way to dispatch these events is by creating them in the browser implementation itself. Sending OS-specific input messages to the browser's window has the disadvantage that the browser being automated may not be properly isolated from a user accidentally modifying input source state. Use of an OS-level accessibility API has the disadvantage that the browser's window must be focused, and as a result, multiple WebDriver instances cannot run in parallel.

    • An advantage of an OS-level accessibility API is that it guarantees that inputs correctly mirror user input, and allows interaction with the host OS if necessary. This might, however, have performance penalties from a machine utilisation perspective.

  • Additionally,

    • Robot Class is used to generate native system input events for the purposes of test automation, self-running demos, and other applications where control of the mouse and keyboard is needed. The primary purpose of Robot is to facilitate automated testing of Java platform implementations. Using the class to generate input events differs from posting events to the AWT event queue or AWT components in that the events are generated in the platform's native input queue. For example, Robot.mouseMove will actually move the mouse cursor instead of just generating mouse move events.

  • Finally, as per Internet Explorer and Native Events:

    • As the InternetExplorerDriver is Windows-only, it attempts to use so-called "native", or OS-level events to perform mouse and keyboard operations in the browser. This is in contrast to using simulated JavaScript events for the same operations. The advantage of using native events is that it does not rely on the JavaScript sandbox, and it ensures proper JavaScript event propagation within the browser. However, there are currently some issues with mouse events when the IE browser window does not have focus, and when attempting to hover over elements.

  • Browser Focus:

    • The challenge is that IE itself appears to not fully respect the Windows messages we send the IE browser window (WM_MOUSEDOWN and WM_MOUSEUP) if the window doesn't have the focus. Specifically, the element being clicked on will receive a focus window around it, but the click will not be processed by the element. Arguably, we shouldn't be sending messages at all; rather, we should be using the SendInput() API, but that API explicitly requires the window to have the focus. We have two conflicting goals with the WebDriver project.

    • First, we strive to emulate the user as closely as possible. This means using native events rather than simulating the events using JavaScript.

    • Second, we want to not require focus of the browser window being automated. This means that just forcing the browser window to the foreground is sub-optimal.

Conclusion

Always keep the Test Environment seperate from Development Environment and absolutely free from Manual Intervention.

undetected Selenium
  • 183,867
  • 41
  • 278
  • 352
  • 1
    Thank you for your answer! This makes sence. Ideally I have to use separate server to run my tests. – Andrei Suvorkov Sep 04 '18 at 11:17
  • @DebanajanB will it be problem ,if i minimize browser when it comes up. will my test run without fail ? – jsduniya Feb 17 '20 at 09:14
  • @jsduniya I have listed all the impacts with respect to _Action_ class, _clicks_, _Native Events_ and _Mouse Events_ in separate sections. Please go through the answer once and let me know if any questions. – undetected Selenium Feb 17 '20 at 09:17
  • @DebanjanB Thank you, I am finding hard to find my issue in that details, my question is even minimizing browser window will effect my test cases ? because i am not doing any event operations on browser viewport which test case are running i'm just clicking on minimize icon(-) of browser. – jsduniya Feb 17 '20 at 10:01
  • @jsduniya I have added one more canonical duplicate target. Let me know if you have any questions. – undetected Selenium Feb 17 '20 at 10:06
  • @DebanjanB I have upvoted that answer also, thank you that solved my problem. – jsduniya Feb 17 '20 at 10:13
2

Whether the browser appears over your current browser, or in the background, depends on the driver implementation and changes from browser to browser - it is not dependent on Selenium or Serenity. However I usually run the tests in chrome in headless mode, which removes the issue entirely.

John Smart
  • 969
  • 1
  • 5
  • 5