-1

When the automation starts, I want to hide the Chrome window till the end of execution but the Chrome window pops up on every opening or switching of tabs.

undetected Selenium
  • 183,867
  • 41
  • 278
  • 352
morsali Younesse
  • 1
  • 1
    Have you tried running `--headless`? – CEH Jan 23 '20 at 18:57
  • Does this answer your question? [How to start ChromeDriver in headless mode](https://stackoverflow.com/questions/45130993/how-to-start-chromedriver-in-headless-mode) – Brydenr Jan 23 '20 at 19:08

1 Answers1

0

When you execute your tests through your Automation Framework using Selenium you must not hide the Chrome window as Selenium needs the focus on the Browser Context which renders the HTML DOM.

Even if you try to hide the window, it may popup as, 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.).

Moreover, 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.

References

You can find a couple of relevant discussions in:

undetected Selenium
  • 183,867
  • 41
  • 278
  • 352