Where can I find a standalone trace-viewer (web app)

[slang25]

@pavelfeldman @JoelEinbinder I'm super impressed with playwright and the trace viewer.

I'm looking to bundle up the viewer with my build artifacts to make viewing the traces seamless (CORS & Auth on my artifacts make the public app tricky). I cannot seem to find an up-to-date version.

The trace folder on this repo seems to be an outdated version.

Thanks! Stu

[slang25]

To give the wider context, I have a TeamCity server which will collect and serve the trace zip files, I'd like to generate a url like https://trace.playwright.dev/?trace=https://...my-trace-file.zip

From a HTTP perspective these files are served requiring basic auth, but I also have a proxy that doesn't require auth (internal and only accessible within our network). Unfortunately the browser denies the fetch request due to CORS, so adding a Access-Control-Allow-Origin: * header on your side might also solve my problem.

[slang25]

The more I think this over, the more I think my request here is for you to add Access-Control-Allow-Origin: * to the https://trace.playwright.dev site and the cli self-hosted version.

Otherwise the ?trace=https://some-otherhost/my-trace.zip functionality will never be useful.

[slang25]

I've taken a look at this again, it looks like this header is being set in the cli hosted version and on `https://trace.platwright.dev/', however I'm getting the request blocked when the service worker is making the request.

I've done a bit of reading about services workers with CORS, however I still don't really understand why this isn't working.

The context endpoint returns a 500 with:

error: "Could not load trace from https://myhost/mytrace.zip. Make sure a valid Playwright Trace is accessible over this url."

The request made by the service worker looks like this in devtools:

[pavelfeldman]

CORS works the other way around, Access-Control-Allow-Origin is a response header that specifies origins that can access your zip files. So your server should return

Access-Control-Allow-Origin: https://trace.playwright.dev

That way when trace viewer reaches for the trace files, it can get them.

[pavelfeldman]

Here is another workaround for you: every time we make an html report, we bundle the trace viewer with it. So:

• Make sure your test produces traces
• Run it with --reporter=html

in the playwright-report, you'll get a trace folder with the deployed version of the trace viewer. We can consider exposing npx playwright deploy-trace-viewer that does it directly.

[slang25]

Thanks!

Ah 🤦 my bad, I thought it was the other way around. At the moment I have Access-Control-Allow-Origin: * from my server, however I'll try calling out the playwright doman explicitly 😄

I'm using playwright-dotnet, so I presume that rules out the reporter option for now. I'd love to have a way to have a static file dumped into our CI artifacts, I was using the version linked to in the OP but it wasn't working as it was outdated.

[slang25]

For anyone finding this issue, I finally figured out what I was doing wrong. If you are serving your own trace files and want to view them via https://trace.playwright.dev, you will need:

• To serve your files with a Access-Control-Allow-Origin: https://trace.playwright.dev header (or *)
• To allow HEAD requests, and to have the above CORS header on this response
• A Content-Length header on the HEAD reponse.

The last 2 points took me a while to figure out.

[slavaGanzin]

@pavelfeldman Hi there, so is there any way to host trace viewer on my own infrastructure?

Can I just serve trace folder with nginx, for example?

I know about npx playwright show-trace, but it launches separate app, but I want it just to be served on my server.

[monkekode]

@pavelfeldman Hi. I have a similar issue that a self-hosted trace viewer would solve - I have a trace file accessible over HTTP - it's in on a VPN, so there is encryption still. I can only load trace.playwright.dev over https, but then I have a mixed-content error since I can't download the http trace file from a https page.

[alisterscott]

Wow this works with Github Pages files no config changes needed :)

https://trace.playwright.dev/?trace=https://alisterscott.github.io/media/trace.zip

[plessbd]

Dont mean to resurrect an old thread, but I needed this for an internal project as well.

I was able to get something working by:

1. checkout github.com:microsoft/playwright
2. npm i
3. npm run build
4. serve up packages/playwright-core/lib/webpack/traceViewer
   • docker run -p 127.0.0.1:8080:80 -v packages/playwright-core/lib/webpack/traceViewer:/usr/share/nginx/html nginx

Note You will need to serve up as https if you are not using looalhost due to the use of webworkers

[d-colwell]

Dont mean to resurrect an old thread, but I needed this for an internal project as well.

I was able to get something working by:

1. checkout github.com:microsoft/playwright

2. npm i

3. npm run build

4. serve up packages/playwright-core/lib/webpack/traceViewer

   • docker run -p 127.0.0.1:8080:80 -v packages/playwright-core/lib/webpack/traceViewer:/usr/share/nginx/html nginx

Note You will need to serve up as https if you are not using looalhost due to the use of webworkers

Minor update, in the latest version, you should run

• docker run -p 127.0.0.1:8080:80 -v packages/playwright-core/lib/vite/traceViewer:/usr/share/nginx/html nginx

since the build for this component is no longer with Webpack. The webpack dir is still there tho which creates some confusion