Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug]: UI Mode with subpath proxying does not report traces during test #33705

Open
GLeurquin opened this issue Nov 21, 2024 · 4 comments · May be fixed by #33771
Open

[Bug]: UI Mode with subpath proxying does not report traces during test #33705

GLeurquin opened this issue Nov 21, 2024 · 4 comments · May be fixed by #33771
Assignees
Labels

Comments

@GLeurquin
Copy link

Version

1.49.0

Steps to reproduce

Following on this issue: #29564

Using the playwright UI to run any test.

In my case, the playwright UI is running inside a docker running VSCode's codeserver instance. When the UI mode is started (on port 9501), it is proxied on a path that looks like this: https://mydomain/proxy/9501/trace/uiMode.html

Hence all api requests made by playwright UI must include the prefix /proxy/9501, especially for the /trace endpoint. This is already the case for most requests made by UI mode, but not for trace requests happening during the execution of a test (the ones asking for a .json file that is generated by the trace server), where an absolute path is used instead, which prevents the UI from displaying ongoing progress in the test.

  • /trace/contexts?trace=... use relative paths correctly --> https://mydomain/proxy/9501/trace/contexts?trace=...
  • /trace/file?path=my_trace.zip use relative paths correctly. --> https://mydomain/proxy/9501/trace/file?path=my_trace.zip
  • /trace/file?path=my_trace.json use an absolute path which makes them fail. --> https://mydomain/trace/file?path=my_trace.json (no /proxy/9501)

The issue only happens for network calls asking for a JSON trace (zip trace and contexts work)

I think the issue may come from here:

const url = new URL('trace/file', this.baseUrl);

altough I'm not familiar enough with the code to be 100% sure.

In the sw.bundle.js file that is shipped with the playwright package, this is the line that causes the issue (there are 2 such lines):
fetch("/trace/file?path="+encodeURIComponent(t))

Replacing it by

fetch("./file?path="+encodeURIComponent(t))

In my case solves it, but I'm aware it's a fix inside a bundled file, which is not ideal.

Expected behavior

Running a test in a playwright UI running behind a proxy should display test progress during the test.

Actual behavior

Running a test in a playwright UI running behind a proxy does not display test progress during the test, but only reports on the status when the test ends. A bunch of network errors are seen in the network debug tab of chrome.

Additional context

No response

Environment

System:
    OS: Linux 5.10 Ubuntu 22.04.4 LTS 22.04.4 LTS (Jammy Jellyfish)
    CPU: (4) x64 Intel(R) Xeon(R) Platinum 8375C CPU @ 2.90GHz
    Memory: 13.19 GB / 15.35 GB
    Container: Yes
  Binaries:
    Node: 20.15.1 - ~/workspace/.config/versions/node/v20.15.1/bin/node
    npm: 10.9.0 - ~/workspace/.config/versions/node/v20.15.1/bin/npm
  Languages:
    Bash: 5.1.16 - /usr/bin/bash
  npmPackages:
    @playwright/test: ^1.49.0 => 1.49.0
@dgozman
Copy link
Contributor

dgozman commented Nov 21, 2024

Assigning to @Skn0tt that has recently touched this area to figure things out.

@Skn0tt
Copy link
Member

Skn0tt commented Nov 25, 2024

I'll validate this next, but I believe this bug existed before 1.49, and is already fixed on main by 445ff73.

@Skn0tt
Copy link
Member

Skn0tt commented Nov 25, 2024

I've reproduced this behaviour on release-1.49 branch using Caddy and this config to setup a reverse proxy:

http://localhost:3000 {
    handle_path /subdir/* {
        reverse_proxy localhost:4000
	}	
}

It's fixed on main. We could try cherry-picking 445ff73 over to 1.49.1, but it would probably need to be more than one commit.

@Skn0tt
Copy link
Member

Skn0tt commented Nov 25, 2024

I verified it also exists on release-1.48, so this isn't a regression. The fix will ship as part of 1.50, and i'll try writing a test to ensure this doesn't break again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
3 participants