[Feature]: Save code output file when launching recorder App

[ATarring]

🚀 Feature Request

Playwright.ps1 codegen allows for an -output param to specify an automatic output file without user interaction on tha inspector UI save button.

Can we exend this function to the Recorder App and through page.PauseAsync() in Playwright-dotnet

Example

Primarily in playwright-dotnet allow page.PauseAsync() to be overloaded with output parameter like so:

page.PauseAsync("./folderLocation/output.cs")

Motivation

The functionality already exists n the recorder App this and is available in tools like playwright.ps1, the parameters just need to be extended out to the protocol validator to allow consuming tools to pass the param.

I currently have a need to pass this output via the Playwright .net libraries page.PauseAsync() method to enable automatic codegen file saving, which programatically inaccessable currently.

[ATarring]

PR's aleady created for this function:

• feat(protocol): add outputFile parameter to browserContext.pause #41544
• feat(pag) Add outputLocation parameter to page.pause() playwright-dotnet#3331

[Skn0tt]

Could you please elaborate on the workflow you're embedding this in? We'd like to understand more about the usecase.

[github-actions]

Hi, I'm the Playwright bot and I took a first look at this.

This is a reasonable, well-scoped feature request, and you're right that most of the machinery already exists — it just isn't reachable from page.pause(). Quick verdict: valid request; the codegen output-file plumbing is already there, but the pause() path deliberately doesn't use it.

Two separate code paths land on the same recorder UI:

• codegen / enableRecorder already accepts an outputFile. The CLI wires -o/--output straight through (browserActions.ts → context._enableRecorder({ outputFile })), and the recorder writes to it via a ThrottledFile (recorderApp.ts).
• page.pause() takes a different route: the debugger pauses and calls RecorderApp.showInspectorNoReply(context), which builds the recorder with empty params (Recorder.forContext(context, {})) — so there's nowhere to pass an output path today.

So the gap is exactly as you describe: the recorder can already save to a file, but page.pause() (and therefore .NET's Page.PauseAsync) has no way to hand it one.

Where this would need to hook in

• packages/playwright-core/src/server/recorder/recorderApp.ts — showInspectorNoReply passes {}; that's the empty-params call site.
• packages/playwright-core/src/server/browserContext.ts — the page.pause() → debugger → inspector flow.
• packages/playwright-core/src/server/dispatchers/browserContextDispatcher.ts — pause() is currently a no-op (// Debugger will take care of this.), so an outputFile param would need threading from the client pause call down to the recorder.
• The public surface is the real design question: page.pause() is a debugging primitive, and adding a codegen outputFile argument touches the public API across all language bindings (JS, Python, Java, .NET), so it's a maintainer call on whether pause() should grow that option or whether this belongs on a separate codegen-oriented entry point.

For the record, the linked PR #41544 (which added outputFile to the browserContext.pause protocol) is currently closed, so this isn't wired up on tip-of-tree yet.

I'm a bot doing a first pass, so I'll leave the design decision to the maintainers.

_{Triage run.}

[ATarring]

Could you please elaborate on the workflow you're embedding this in? We'd like to understand more about the usecase.

I am working on a tooling implentation in c# dotnet that utalises Playwright .net as a core library.
In this i utalise Page.Pause.Async() to invoke the Inspector Window allowing Non-Technical consumers to capture input steps.

Currently the consumer would then have to remember to manually copy or manually save the generated code from the Inspector Window (which is proving easily forgettable). And manually supply that content back to my tooling.

Introducing the output functionality removes this manual copy/save need as well as allow the tool to set the output location for later automatic retrieval.

[Skn0tt]

Gotcha, that makes sense. You have tooling for having non-technical folks generate tests, and you want to eliminate the copy/paste step from your workflow.

Instead of an outputFile param, how would you like page.pause() having the generated code in its return value instead?

[ATarring]

That would also work, currently on the playwright-dotnet side page.pauseAsync() returns void.

I approached the concept via output parameter for 2 reasons:

• the optional overload approach avoided changing method contract for existing users.
• the output functionality already exists on the recorder and just needed passing through from the protocol layer.

For my specific usage it would be preferable to include an additional page.pauseAsync() that directly returns the generated code as that will avoid executing quite a few file operations over the course of an execution.

I would also still suggest supplying the File Write output parameter as an option as it is very likly to be benefitial flow to other users for relitivley little additional effot.