[Bug]: Tracing setSources(true) produces no sources when the browser is connected via connect()

[janne-hyoetylae-med]

Version

1.61.0

Steps to reproduce

1. src/main/java/org/example/TraceSources.java:

package org.example;

import com.microsoft.playwright.Browser;
import com.microsoft.playwright.BrowserContext;
import com.microsoft.playwright.Page;
import com.microsoft.playwright.Playwright;
import com.microsoft.playwright.Tracing;
import java.nio.file.Paths;

public class TraceSources {
  public static void main(String[] args) {
    String wsEndpoint = args.length > 0 ? args[0] : null;

    try (Playwright playwright = Playwright.create()) {
      Browser browser = wsEndpoint == null
          ? playwright.chromium().launch()
          : playwright.chromium().connect(wsEndpoint);

      BrowserContext context = browser.newContext();
      context.tracing().start(new Tracing.StartOptions()
          .setScreenshots(true)
          .setSnapshots(true)
          .setSources(true));

      Page page = context.newPage();
      page.navigate("https://playwright.dev");
      page.getByText("Get started").click();

      context.tracing().stop(new Tracing.StopOptions()
          .setPath(Paths.get(wsEndpoint == null ? "trace-launch.zip" : "trace-connect.zip")));
      browser.close();
    }
  }
}

2. Point PLAYWRIGHT_JAVA_SRC at the source root, then run once with a locally
   launched browser and once against a Playwright server, e.g. if Maven project:

export PLAYWRIGHT_JAVA_SRC=src/main/java

# A: locally launched browser
mvn -q compile exec:java -Dexec.mainClass=org.example.TraceSources

# B: connected browser. Start the server in another shell first:
#   npx playwright@1.61.0 run-server --port 3000
mvn -q compile exec:java -Dexec.mainClass=org.example.TraceSources \
    -Dexec.args="ws://localhost:3000/"

4. Open both in the trace viewer:

mvn exec:java -Dexec.mainClass=com.microsoft.playwright.CLI -Dexec.args="show-trace trace-launch.zip"

mvn exec:java -Dexec.mainClass=com.microsoft.playwright.CLI -Dexec.args="show-trace trace-connect.zip"

Expected behavior

The Source tab in the trace viewer shows TraceSources.java with the selected action's line highlighted, for both traces.

Actual behavior

A (launch)
Source tab: shows TraceSources.java, current action highlighted.

B (connect)
Source tab: empty. Actions still show a file name and line number, but the file
content is not in the archive, so no code is displayed.

No exception is thrown and nothing is logged. The trace is written successfully and
is otherwise complete — screenshots, snapshots and network are all there. Only the
sources are missing.

Additional context

Possible cause:
We have not confirmed this, but source collection looks like it happens purely
client-side: the per-call Java stacks are pushed to the local driver's LocalUtils via
addStackToTracingNoReply, and stop() writes trace.stacks and the
resources/src@*.txt blobs from that stack session. Connection.internalSendMessage
appears to send that message over the same transport as the API call it belongs to,
which for a connected browser is the remote connection rather than the local driver.
If so, the local stack session stays empty and both entries are skipped.

Environment

• Operating System: Ubuntu 22.04
• CPU: x64
• Browser: Chromium (maybe the others as well)
• Java Version: 21

[Develop-KIM]

The repo already has a test for this and it fails today — TestBrowserTypeConnect#shouldRecordTraceWithSources ends up with 0 source entries in the trace.

Your read of the cause is right. Connection.internalSendMessage sends addStackToTracingNoReply to localUtils.guid over this.transport, and for a browser from connect() that's the server pipe rather than the driver that owns LocalUtils. The rest of tracing goes through the LocalUtils channel object (tracingStarted, zip), so those land on the driver connection and the stack session opened there never receives anything. Routing that one call through localUtils.connection makes the test pass.

It has never run on CI: the main mvn test step has no PLAYWRIGHT_JAVA_SRC so the assumption skips it, and the sources step filters on -D test=*TestTracing*, which doesn't match that class.

I have the fix locally with TestBrowserTypeConnect and TestTracing green. Happy to open a PR if you assign this to me.