Summary
Starting a live recording always opens the browser on a blank page. There is no way — at project level or anywhere else — to tell the recorder which address a recording should start on, so the tester types the application's address by hand at the start of every recording, and nothing in the product remembers it.
Root cause
The codegen command line is assembled without a URL. TestCaseComponent.launchPlaywright, TestCaseComponent.java#L933-L943:
public void launchPlaywright(File outputFile) throws IOException {
String escapedPath = outputFile
.getAbsolutePath()
.replace("\\", "\\\\")
.replace("\"", "\\\"");
String processArgs = "codegen --target java --output \"" + escapedPath + "\"";
runPlaywrightProcess(processArgs);
playwright codegen takes an optional URL as its first positional argument. It is never supplied, so codegen opens about:blank.
Nothing else in the flow supplies one either:
RecordingTargetDialog collects a scenario name and a test case name (plus the reusable-scenario equivalents). Its only text fields are newScenarioNameField, newScenarioTestCaseField, newReusableNameField, newReusableTestCaseField — there is no address field.
- There is no start-address setting in the project settings tree.
ProjectSettings.save() enumerates the project's settings groups and none of them carries one; searching the branch for any startUrl / start_url-shaped key returns nothing at all.
Still current on the branch head: at release/3.1.0 @ 7bc763b6 the same statement is unchanged (now at TestCaseComponent.java:947), and the dialog still has no address field.
Why it is worth fixing rather than living with
- The address is a property of the project, not of the person recording. A project is written against one application, but every recording re-asks every user for the same value.
- Where environments of the same application differ only by hostname, retyping is a per-recording chance to record against the wrong one — and that mistake leaves no trace on screen. The wrong environment renders exactly like the right one and the recorded steps look correct. It surfaces later as an unexplained failure somewhere else, or not at all.
- It is one of the first things a new user has to be told that the product could simply have remembered.
Suggested fix
An optional project-level start address, resolved as configured value → today's behaviour when unset, so that installs that set nothing behave exactly as they do now.
- A key in a project settings group plus a field on the Settings screen that writes it. Both belong in the same change — a setting the product reads but no screen writes is a properties file users have to be told the name of, which is worse than the blank page it replaces because it looks configurable and is not.
launchPlaywright appends the value as codegen's first positional argument when set, and changes the command not at all when unset.
- Validate before use — require an absolute
http/https URL with a host, and refuse anything else with a console message rather than passing it on. This matters more than it might look: the command is assembled as a single string and handed to a shell. startPlaywrightProcess, TestCaseComponent.java#L896-L906 builds java -cp "<classpath>" com.microsoft.playwright.CLI <processArgs> and runs it via cmd /c or bash -l -c, so an unvalidated value would be shell input, not merely an argument.
Optionally, a per-recording override in RecordingTargetDialog, prefilled from the project value, for the occasional recording that has to start somewhere else.
Happy to prepare a PR along these lines if the approach looks right — in particular whether you would prefer the key in an existing settings group or a new one.
Environment
Built from source, release/3.1.0 @ 15274331; re-checked against branch head 7bc763b6. Windows 11, JDK 17.
Summary
Starting a live recording always opens the browser on a blank page. There is no way — at project level or anywhere else — to tell the recorder which address a recording should start on, so the tester types the application's address by hand at the start of every recording, and nothing in the product remembers it.
Root cause
The
codegencommand line is assembled without a URL.TestCaseComponent.launchPlaywright,TestCaseComponent.java#L933-L943:playwright codegentakes an optional URL as its first positional argument. It is never supplied, so codegen opensabout:blank.Nothing else in the flow supplies one either:
RecordingTargetDialogcollects a scenario name and a test case name (plus the reusable-scenario equivalents). Its only text fields arenewScenarioNameField,newScenarioTestCaseField,newReusableNameField,newReusableTestCaseField— there is no address field.ProjectSettings.save()enumerates the project's settings groups and none of them carries one; searching the branch for anystartUrl/start_url-shaped key returns nothing at all.Still current on the branch head: at
release/3.1.0@7bc763b6the same statement is unchanged (now atTestCaseComponent.java:947), and the dialog still has no address field.Why it is worth fixing rather than living with
Suggested fix
An optional project-level start address, resolved as configured value → today's behaviour when unset, so that installs that set nothing behave exactly as they do now.
launchPlaywrightappends the value as codegen's first positional argument when set, and changes the command not at all when unset.http/httpsURL with a host, and refuse anything else with a console message rather than passing it on. This matters more than it might look: the command is assembled as a single string and handed to a shell.startPlaywrightProcess,TestCaseComponent.java#L896-L906buildsjava -cp "<classpath>" com.microsoft.playwright.CLI <processArgs>and runs it viacmd /corbash -l -c, so an unvalidated value would be shell input, not merely an argument.Optionally, a per-recording override in
RecordingTargetDialog, prefilled from the project value, for the occasional recording that has to start somewhere else.Happy to prepare a PR along these lines if the approach looks right — in particular whether you would prefer the key in an existing settings group or a new one.
Environment
Built from source,
release/3.1.0@15274331; re-checked against branch head7bc763b6. Windows 11, JDK 17.