feat(web): open HTML files in the browser from the files context menu

[mrmg]

Problem

Right-clicking an HTML file in the files panel only offers "Copy mention" and "Add to chat". Opening the file drops you into the code view, and the only way to see it rendered is to first open the file and then find the small globe button in the preview header. Nothing in the tree menu hints a browser view exists.

Fix

• Add "Open in browser" to the files tree context menu for previewable files (.html/.htm/.pdf), shown as the first item.
• The item only renders when the runtime can actually do it: isPreviewSupportedInRuntime() (integrated browser present) plus an environment HTTP base URL. On web and mobile it simply doesn't appear, matching the existing header button.
• FilePreviewPanel.handleOpenInBrowser now takes the file path and resolves it against cwd, so the header globe button and the new menu item share one code path (including its error toast).

Test plan

• tsgo --noEmit, vp lint, FilePreviewPanel unit tests (8/8)
• Desktop: right-click index.html in files → menu shows "Open in browser" → opens the file in the browser surface
• Menu item is absent in runtimes without the integrated browser (web client)
• Manual pass on desktop: confirm menu item on a .pdf too

Screenshots

Made with GLM-5.3-Flash in T3 Code.

---

Note

Low Risk
UI-only file explorer and preview wiring with a small, well-scoped path helper; no auth or persistence changes.

Overview
Adds Open in browser as the first item on the file tree right-click menu for workspace files that support integrated preview (e.g. HTML/HTM/PDF), when the runtime has an integrated browser and an environment HTTP base URL.

The tree wires this through a new optional onOpenInBrowser prop from FilePreviewPanel, which reuses the same openFileInPreview flow and error toast as the preview header globe button. handleOpenInBrowser now takes a workspace-relative path instead of relying on a pre-resolved absolute path.

Path resolution for the file panel switches from terminal-link resolvePathLinkTarget to new resolveWorkspaceFilePath, so a leading ~/ inside the workspace is treated as a literal folder name, not home-directory expansion.

^{Reviewed by Cursor Bugbot for commit 041fff6. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Add "Open in browser" action to FileBrowserPanel context menu

• Adds an optional onOpenInBrowser callback to FileBrowserPanelProps that displays an "Open in browser" context menu item for eligible files
• FilePreviewPanel provides this callback when the runtime supports browser preview and an environment HTTP base URL is available
• Introduces resolveWorkspaceFilePath in terminal-links.ts to resolve relative paths against the workspace root
• Behavioral Change: FilePreviewPanel resolves browser-opening and preview file paths using resolveWorkspaceFilePath, which treats a leading ~/ segment as a literal directory rather than expanding it to the user's home directory

^{Macroscope summarized 041fff6.}

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This PR adds a new file-browser context-menu workflow for opening HTML and PDF files in the integrated browser, plus workspace path-resolution behavior. The change is localized and user-initiated, but the new interaction lacks targeted test coverage and should receive human review.

^{You can add or adjust custom eligibility rules. Learn more.}

[juliusmarminge]

Note

This comment is posted by Julius' dot

Closing under the prior-approval rule. The preview header already opens these files in the integrated browser; this adds another interaction to address discoverability. There is no linked maintainer approval for the new menu action. Please discuss the discoverability problem in Ideas and obtain scope approval before requesting reconsideration.