← Back to microsoft/playwright
microsoft / playwright · Issue No. 41306
Allow chrome to open in headful mode but in the background without removing focus from an active window. Firefox already supports this via Playwright flags, but Chrome does not have a flag.
This is a reincarnation of https://github.com/microsoft/playwright/issues/4822 which had 36+ people support this motive: https://github.com/microsoft/playwright/issues/4822#issuecomment-971881082 but the issue was already closed
There is an open PR for this https://github.com/microsoft/playwright/pull/41282 description:
browserType.launch({ createPagesInBackground: true }) option (default false, no behavior change otherwise).background: true to Target.createTarget, so newPage() no longer activates the browser app and steals OS focus from the user (verified on macOS).document.hasFocus() / visibilityState are unaffected thanks to focus emulation, and page.bringToFront() still raises the window. Skipped for headless (headless shell does not support the parameter) and Android.-foreground is passed (older builds did), and WebKit never steals.-foreground CLI arg — a different mechanism than Chromium's per-newPage() foreground target creation, and there is no juggler equivalent of background: true. Affected Firefox users can already opt out via ignoreDefaultArgs: ['-foreground'].-foreground in defaultArgs() when the option is set; left out for now since it is untestable against current builds and changes launch activation rather than page creation. Happy to generalize if preferred.fixes https://github.com/microsoft/playwright/issues/4822
I have a script launches Okta and automatically re-authenticates for me. If the script runs while I'm typing in a different browser, Chrome focuses and my typing is interrupted.
There is currently no way to activate Chrome in the background during headful mode without stealing focus from active tasks. This is particularly annoying when trying to work in multiple contexts.
Relay reads this issue against the repository's contribution signals: the files it is likely to touch, how the maintainers triage work this size, and what the first contribution would exercise.
The full analysis for this issue is still being assembled. Until then, the description above and the thread on GitHub are the most reliable context.