API gaps blocking a full Playwright exit: pdf(), network events, emulation presets (measured list)

[Bervinm]

Context

We run a production content site and have migrated our browser automation toward Stagehand 4.0.0, primarily for self-healing selector resolution against a live Chrome over CDP. It works well: healed selectors have kept two brittle UI-driving pipelines alive with zero selector maintenance.

We would like to drop Playwright entirely, and we measured exactly what still blocks that. Across 15 automation scripts (QA sweeps, PDF rendering, screenshot/chart rendering, scraping, UI publishing), 13 are blocked by missing APIs. Ranked by how many scripts each gap blocks:

Blocked scripts	Missing API	Notes
4	page.pdf()	Even a thin passthrough to CDP Page.printToPDF would cover it
3	context emulation options	userAgent, deviceScaleFactor, reducedMotion etc. at context/page creation; viewport alone is already covered by setViewportSize
2	device presets (a la playwright.devices)	hand-rolling UA + viewport + touch flags per device is error-prone
2	page.on("response" / "requestfailed" / "pageerror")	today page.on supports only console; response/network events are the backbone of any QA sweep that needs to catch non-200s and dead assets
2	role/text locator builders (getByRole, getByText)	CSS/XPath work, but role selectors are what keep QA and publishing scripts readable
1	page.route() request interception
1	page.waitForFunction()	poll-on-a-timer works but is noisy
1	page.setContent()	workaround exists via evaluate, listed for completeness
1	page.content()	trivial via evaluate(() => document.documentElement.outerHTML)
1	page.waitForURL()
1	fine-grained keyboard (keyboard.down/up, modifiers)	page-level type/key_press exist today

Ask

Are any of these on the roadmap? The top three (PDF, network/error events, context emulation + device presets) would unblock 9 of our 13 blocked scripts on their own, and all three look like thin passthroughs to capabilities CDP already exposes. Happy to provide more detail on any of the use cases, or to test previews.

[Bervinm]

I'm the one running this setup.

Since filing, I went back and checked whether these gaps are actually hard, or just unbuilt.

I connected a raw CDP socket to a headless Chrome, no Playwright anywhere, and tried the top blockers by hand:

What I need	What I called	Result
page.pdf()	Page.printToPDF	valid PDF, 9,338 bytes
context emulation	Emulation.setDeviceMetricsOverride + setUserAgentOverride + setEmulatedMedia	device scale factor, mobile UA and prefers-reduced-motion all applied
page.on("response")	Network.enable + Network.responseReceived	response statuses captured, which is the entire QA use case
page.setContent() / page.content()	Page.setDocumentContent / DOM.getOuterHTML	both round-tripped

So the three gaps I asked about are wrappers over calls Chrome already answers.

That's why I'm pushing on it rather than quietly working around it.

I can write the shim myself in an afternoon. But then I'm maintaining my own PDF and network layer for the life of the project, and so is everyone else who lands on this issue.

We drive a production site from this, and self-healing has genuinely earned its place. Right now I keep both libraries installed for four scripts that need page.pdf(), and that's the only thing between us and dropping Playwright completely.

Is there a roadmap position for the passthroughs? I'm happy to test a preview build against the real scripts and report back what breaks.

[seanmcguire12]

hey @Bervinm ! thanks for the feedback here, this is awesome. i think all of this is aligned & i’m happy to add to our roadmap. at first glance, the only one i want to spend a little extra time thinking about is getByRole. i wonder if this could just be baked into the existing locator primitive?

[nagalikith]

opened #2819 for the pdf part — thin wrapper over Page.printToPDF with playwright-style options.