[Feature]: Support for redirecting trace viewer to public hosted viewer

[prakash-amit]

🚀 Feature Request

Problem:
When HTML reports are hosted on Azure Blob Storage or other remote locations,
users need a way to open traces in the public trace viewer (trace.playwright.dev)
instead of the embedded viewer, as the embedded viewer cannot access remote traces
with proper authentication.

Proposed Solution:
Add support for a USE_PLAYWRIGHT_PUBLIC_TRACE_VIEWER environment variable
that redirects all trace links in the HTML reporter to https://trace.playwright.dev/.

Use Case:

• HTML reports hosted on Azure Blob Storage with SAS token authentication

Expected Behavior:
When USE_PLAYWRIGHT_PUBLIC_TRACE_VIEWER=true:

• All trace links redirect to public viewer
• SAS tokens from HTML report URL are preserved and appended to trace URLs
• Works across all trace link locations

Example

No response

Motivation

Current Limitation:

When Playwright HTML reports are hosted on remote storage (Azure Blob Storage, AWS S3, etc.), the embedded trace viewer cannot access trace files due to cross-origin restrictions and authentication requirements. Users are forced to download traces manually and open them locally, which is cumbersome and breaks the seamless debugging workflow.

How This Makes Playwright Better:

✅ Seamless Remote Debugging - One-click access to traces from remotely hosted reports

✅ Better Collaboration - Teams can easily share reports with proper trace access, even with external stakeholders who don't have local access to artifacts

✅ Zero Configuration - Simple environment variable, no code changes needed

✅ Backward Compatible - Opt-in behavior; existing workflows remain unchanged

✅ Consistent Experience - The public trace viewer (trace.playwright.dev) already handles remote traces perfectly, this just makes it accessible from HTML reports

Impact:

This feature enables the full power of Playwright's trace viewer for teams using modern CI/CD pipelines with cloud-hosted artifacts, making the debugging experience as smooth for remote reports as it is for local development.

[yury-s]

Proposed Solution:
Add support for a USE_PLAYWRIGHT_PUBLIC_TRACE_VIEWER environment variable
that redirects all trace links in the HTML reporter to https://trace.playwright.dev/.

Can you explain why showing the trace inside a page served off 'https://trace.playwright.dev/' would work when it doesn't work for showing same trace inside the html report hosted on Azure Blob Storage?

SAS tokens from HTML report URL are preserved and appended to trace URLs

As far as I understand this is the key part, you want the SAS token search query parameter to be added to all trace URLs that the html report uses. If we propagate the query parameters to the trace URLs, the traces should work both inside the html report and if opened via https://trace.playwright.dev/. Can you confirm that?

[prakash-amit]

Hi @yury-s ,

You rightly mentioned that key point is to have SAS token in each trace URL used for html report. Currently, SAS token propagates till /trace/index.html but not further down the dependencies line for static content like JS, CSS, and image files.

As a workaround, we are trying to open trace.playwright.dev and pass SAS embedded trace zip file which is self-contained. For resolving CORS, we allow list trace.playwirght.dev in Azure Storage Account.

So, if you propagate the query parameters to the trace URLs then it resolves our issue.

[pavelfeldman]

Serving a full web application (HTML, JS, CSS, and Assets) where every single sub-resource requires a SAS token in the query string is considered an anti-pattern for several reasons:

• Caching Issues: Browsers and CDNs treat script.js?token=A and script.js?token=B as different files. This kills cache hits and forces the user to redownload assets frequently.
• Referrer Leakage: If your app links to an external site, the SAS token might be sent in the Referer header to that third party.
• Development Overhead: Standard build tools (Webpack, Vite, etc.) and HTML tags (like <link> or <img>) do not natively "forward" query parameters from the parent URL.
• Token Expiration: If the user stays on the page longer than the SAS token's lifetime, subsequent lazy-loaded chunks or API calls will fail.

Would you consider swapping it for a short-lived HttpOnly cookie? I.e.

• First request uses SAS token
• App exchanges it for a short-lived, HttpOnly cookie
• All internal links become normal

[prakash-amit]

Hi @pavelfeldman ,

I agree on the points raised by you, but Azure Storage does not support HttpOnly cookie approach for accessing blobs. To implement the approach suggested by you, we will have to write our own service such that:

• Browser talk to Service for static files using HttpOnly cookie
• Service connects to customer storage using MI to fetch blobs
• Service returns static files to Browser

But currently hosting Service with MI permission on Customers' Storage Accounts is not in scope for us.

[Skn0tt]

I tried making the query parameter forwarding work with our build setup, but failed - see #38634 (comment).

@prakash-amit I don't think you need a managed identity, the SAS token is enough to authenticate. The service would be a thin proxy that converts search params into cookies, and nothing else.

[Skn0tt]

Mirroring offline discussion here. We discussed that overriding the trace/index.html file to be a redirect to the public trace viewer can work as a user-land implementation of the approach suggested in the issue description.

fs.writeFileSync('playwright-report/trace/index.html', `
  <script>
    const url = new URL(location.href);
    const trace = new URL(url.searchParams.get('trace'));
    trace.searchParams.set('sas_token', url.searchParams.get('sas_token'));
    const publicTraceViewer = new URL('https://trace.playwright.dev/');
    publicTraceViewer.searchParams.set('trace', trace.toString());
    location.href = publicTraceViewer.toString();
  </script>
`);

[pavelfeldman]

Simon, I am not sure your snippet does something, the trace param in stock report is relative or local. But not hosting the app behind sas is great. I am not sure if the report is stock or not though. If client has their own html report, making it work should be straightforward.

[prakash-amit]

As per discussion with Simon, what we are doing is - We have a custom reporter which is a wrapper over html reporter, this custom reporter modifies the content of trace/index.html to be a redirect script to https://trace.playwright.dev/ before uploading it to storage. The script extracts all query parameters from the /trace/index.html url which includes "trace" param as well as SAS token params, in next step SAS tokens are appended as query params in url contained in trace param and trace query param is added to https://trace.playwright.dev, finally page is redirected to https://trace.playwright.dev.

[pavelfeldman]

Should we close this then, or is something is still missing?

[prakash-amit]

I have a query: Is it possible to restructure embedded trace viewer such that there is two parts to it, a TraceViewer tool which can be hosted anonymously in storage and second part is trace data as a single bundle so that we only need to keep that part behind SAS tokens for each individual user?

[pavelfeldman]

That is already the case. HTML report simply bundles a standalone trace viewer app and uses it to show attachments. Exact same structure that you intend to use.