[BUG]: PublishCodeCoverageResults@2 -- "Code Coverage" tab getting blocked in Chrome

[mrairdon-midmark]

New issue checklist

• I searched for existing GitHub issues
• I read pipeline troubleshooting guide
• I checked how to collect logs

Task name

PublishCodeCoverageResults@2

Task version

No response

Issue Description

Viewing the Code Coverage report tab gets me this error:

Environment type (Please select at least one enviroment where you face this issue)

• Self-Hosted
• Microsoft Hosted
• VMSS Pool
• Container

Azure DevOps Server type

dev.azure.com (formerly visualstudio.com)

Azure DevOps Server Version (if applicable)

No response

Operation system

Windows 11

Relevant log output

(index):1 Refused to display 'https://spsprodcus2.vssps.visualstudio.com/' in a frame because it set 'X-Frame-Options' to 'sameorigin'.


(index):1 Unsafe attempt to load URL https://spsprodcus2.vssps.visualstudio.com/_signin?realm=<dev-platform>&reply_to=https%3A%2F%2F<dev-platform>%2F<org-name>%2F<project-id>%2F_apis%2Ftest%2FCodeCoverage%2Fbrowse%2F<run-id>%2F<report-name>%2Findex.html&redirect=1&protocol=cookieless&hid=<session-id>&context=<encoded-context>&lltid=<trace-id>
from frame with URL chrome-error://chromewebdata/. Domains, protocols and ports must match.

Chrome "Debug with AI" analysis

The failure is caused by a security conflict between the <iframe> attributes and the response from the Azure DevOps authentication server.

Specifically, the net::ERR_BLOCKED_BY_RESPONSE combined with the provided HTML snippet reveals three critical issues:

1. The sandbox="" Attribute
The <iframe> has an empty sandbox attribute. An empty sandbox is the most restrictive setting possible. It:

Blocks forms: Prevents the sign-in page from submitting credentials.
Blocks scripts: Prevents the authentication redirect logic from running.
Blocks "Same-Origin" access: Even if the domains matched, the sandbox treats the content as being from a unique, opaque origin.
2. X-Frame-Options: SAMEORIGIN
The response headers from visualstudio.com include x-frame-options: SAMEORIGIN.

This header explicitly tells the browser: "Do not allow this page to be rendered in a frame unless the parent page is on the exact same domain."
Since your parent page is likely dev.azure.com (or a custom domain) and the frame is trying to load spsprodcus2.vssps.visualstudio.com, the browser blocks it to prevent Clickjacking attacks.
3. The 203 Non-Authoritative Information Status
In the context of Azure DevOps, a 203 status during a _signin flow often indicates that the authentication middleware has intercepted the request but cannot complete the handshake within the current context (the restricted iframe).

Full task logs with system.debug enabled

Details

 [REPLACE THIS WITH YOUR INFORMATION] 

Repro steps

[jonatassaraiva]

We are experiencing the same issue, specifically using a Node.js stack with Vitest coverage.

Environment

• Node.js: 22.x
• Test runner: Vitest
• Coverage provider: @vitest/coverage-v8
• Azure DevOps Pipeline
• Agent: ubuntu-latest

Description

The pipeline runs successfully and generates coverage locally, but Azure DevOps does not display the coverage results in the UI.