Sign up
View stargazers12Sign up

[Bug]: Browser tools don't tell agents why a page failed to load#18555

opened10d agobyRrobertnisipeanu

Before submitting

  • I searched existing issues and did not find a duplicate.
  • I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

  1. In a thread, open the Browser panel and load https://self-signed.badssl.com/ (any page that fails to load: an untrusted certificate, a refused connection, a blocked port).
  2. The panel shows Chromium's "This site can't be reached … ERR_CERT_AUTHORITY_INVALID" page.
  3. Ask the agent to call preview_status and preview_snapshot on that tab.

Expected behavior

The browser tools tell the agent why the page did not load: the URL that failed, the browser's error code, and its description.

Actual behavior

preview_status returns only "url": "chrome-error://chromewebdata/" with an empty title, and preview_snapshot has no page text. For a tab the desktop app renders, the failure usually happens before the server connects to the page, so nothing in either result names the error. The agent has to guess (often a self-signed certificate on a LAN device) or ask the user to read the screen.

Impact

Minor bug or occasional failure

Version or commit

main @ 5fe7568e87

Environment

macOS, web dev server (server-rendered tabs); desktop-rendered tabs reasoned from code.

Workaround

The user reads the error page in the Browser panel and tells the agent. For server-rendered tabs, the failed request sometimes appears in preview_snapshot's networkEntries if it has not been pushed out by later requests.

Earlier attempt at a fix: #16835 (closed for incomplete verification).

JJulius Marminge10d ago

Note

Grok responding on behalf of Julius.

Confirmed on main (bed92398): the failure details are already recorded but the agent tools never return them.

  • Both hosts record a LoadFailed nav status with code and description (packages/contracts/src/preview.ts): desktop from did-fail-load in apps/desktop/src/preview/Manager.ts, server tabs in apps/server/src/preview/ServerBrowser.ts. apps/server/src/preview/Manager.ts stores it on the session snapshot and emits a failed event.
  • PreviewAutomationStatus (packages/contracts/src/previewAutomation.ts) has only url/title/loading, so preview_status reports chrome-error://chromewebdata/.
  • The orchestration instructions tell agents to "quote the raw error" for chrome-error:// pages, but no tool exposes one.

Likely fix: add an optional loadError { url, code, description } to the status (and snapshot) output from the session's LoadFailed nav status. Then verify it on both desktop-rendered and server-rendered tabs. That cross-host check is where #16835 fell short.

Related: #17965 (one common trigger, local HTTPS certs). #7212 is a separate UI issue.

JJulius Marminge20h ago

Reproduced on main at 8acbefefc5 on Linux. The real preview broker and ServerBrowser with Chromium returned an empty error-page snapshot and no direct load diagnostic in status or snapshot for https://self-signed.badssl.com/, a local self-signed HTTPS fixture, and Chromium's blocked port 1. Recovery to local HTTP succeeded. The error remains available only in network/action history.

Existing fix #18588 covers this issue; no duplicate fix PR is needed. Live Electron verification is unavailable on this VM.