PW_CHROMIUM_ATTACH_TO_OTHER: is a hidden target a supported way to get a page?

[stickerdaniel]

launch_persistent_context() always opens a window, which is awkward for a long-running background process. --no-startup-window is not a way around it: loadDefaultContextAsIs() waits for a Page event, and that switch is precisely what prevents one, so the launch hangs until it times out.

// coreBundle.js:48754-48757 in patchright 1.60.1
async loadDefaultContextAsIs(progress2) {
  if (!this.possiblyUninitializedPages().length) {
    const waitForEvent2 = helper.waitForEvent(progress2, this, _BrowserContext.Events.Page);
    await progress2.race(Promise.race([waitForEvent2.promise, this._closePromise]));

The alternative that looks viable is to create the page as a hidden target instead:

cdp = await context.new_cdp_session(startup_page)
await cdp.send("Target.createTarget", {"url": nonce_url, "hidden": True, "background": True})

Chromium reports that target as type: "other", so it is only exposed as a Page when PW_CHROMIUM_ATTACH_TO_OTHER is set; without it the session is detached (coreBundle.js:38445-38446). In persistent mode _defaultContext exists and is used as the fallback, so the attach should land.

Two questions before I depend on it:

• the variable is undocumented. Is it part of what patchright intends to keep, or an internal that can go away on the next Playwright bump? It is byte-identical in 1.60.0, 1.60.1, 1.61.1 and 1.61.2.
• driver_patches/crBrowserPatch.ts rewrites CRBrowser. Does anything in it touch target attachment, or is that path stock Playwright?

Happy to send a repro if it helps.

[Vinyzu]

@rakeshutekar Please do not use LLM in any direct communication under any of my Projects. If you do so again i will block/ban you from communicating under any Repo in this Orga.

@stickerdaniel Im giving you the benefit of the doubt here, as im not sure if/how much of your post is AI-generated. If it is, please refrain from doing so.

On your two questions:

1. I think thats a questions for the Playwright Authors, as i cannot understand their undocumented code any better than you can. If you asked them and they cannot/wont answer this clearly ill investigate the question further for you.
2. No, crBrowserPatch.ts does not mess around with Target Attachment. It only touches InitScript Handling, iirc it reverts it back to a previous state after a Playwright Update broke Patchrights logic.

[rakeshutekar]

Noted, and sorry, that's fair. For that comment I did use AI to rewrite it into something more readable. The actual digging (reading through crBrowserPatch.ts, tracing the attach path) was mine, but I ran the write up through an LLM to tidy it up, which I get is exactly what you don't want here. Won't happen again in your repos.

And thanks for confirming the init script thing. I'll take the env variable question upstream to the Playwright authors.

[stickerdaniel]

@Vinyzu Thanks for your clarification on crBrowserPatch.ts. I understand that LLM generated content is a challenge for open source maintainers. Let me give you some context on what I'm trying to build, maybe there's a better way I'm missing:

I want to avoid headless=True, as Chromium prepends "Headless" to the product string, so the UA and sec-ch-ua both say HeadlessChrome. --> a window pops up (expected), but the UA is clean.

To hide the window, I found the solution above that is using hidden target over CDP:

cdp = await browser.new_browser_cdp_session()
await cdp.send("Target.createTarget", {"url": nonce, "hidden": True, "background": True})

This leads to no window on screen, visibilityState = "visible", hasFocus() = true, rAF 122/s against a control visible window at 122/s. The hidden window behaves exactly as a visible one.

The only reason I need PW_CHROMIUM_ATTACH_TO_OTHER is that Chromium reports this target as type: "other", so without the variable it never shows as a Page. Thats why I asked whether it's something you intend to keep.

If there is a saner way to get a headed context with no visible window, I'd rather do that than depend on an undocumented variable.

On asking Playwright first: already did, for the adjacent problem. The --no-startup-window hang is microsoft/playwright#42093. Their bot confirmed the loadDefaultContextAsIs analysis, then it was closed as not planned with "custom browser args are not supported [...] If you don't want a visible window, pass headless=True". Different question than the env var, but I don't expect a clearer answer on an undocumented internal...

[xian0x5a]

a follow-up question, since upstream playwright rejected the the ticket 42093 for --no-startup-window hang, i wonder if it is a proper request to fix it in this repo? it seems to be a simple fix.

a workaround i found is to set ignore_default_args=True and then pass the other flags myself, but that is less convenient.