Make Quarto Posit Workbench aware - #14869
Conversation
handleExternalLinks compared anchor hrefs against the origin the preview server inferred from the request. Behind a proxy the browser is on a different origin, so internal links were classified as external and the embedder opened them in a new browser tab. Compare parsed origins for equality against window.location.origin, still accepting the server-provided origin. Parsing also resolves relative hrefs, which a prefix test always treated as external. Fixes #14865
✅ Snyk checks have passed. No issues have been found so far.
💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse. |
|
|
There was a problem hiding this comment.
No, we don't have an automated e2e test that exercises quarto preview. Nothing in tests/ starts the preview server, and the Playwright suite serves pre-rendered files, so quarto-preview.js is never loaded there. Expanding Playwright to cover it is tracked in #10696.
We only have manual testing through /quarto-preview-test and tests/docs/manual/preview cases.
I verified this one by hand instead, with a viewer-like iframe host page and a reverse proxy on a second origin, so the browser origin differs from the one the preview server infers. On main an internal link click posts openExternal to the parent, with this PR it stays in the pane, and a genuinely external link still posts openExternal. On a plain localhost preview both behave identically, so the common local case is unchanged.
Verifying #14869 needed a way to exercise the code in src/webui/quarto-preview/src/frame/ that only runs inside an embedded viewer (RStudio Viewer, VS Code Simple Browser, Posit Workbench). A plain top-level preview never reaches it, and quarto-cli has no e2e test that starts `quarto preview` at all. - Reference for the `quarto-preview-test` skill covering the iframe + postMessage host page pattern, a throwaway reverse proxy for reproducing a proxied deployment's browser/server origin mismatch, the server's first-request client-injection detection, and the precondition assertion needed before trusting a click result - Test workflows skip `.claude/**`-only changes, since agent config cannot affect build or test outcomes Related to #14869, #10696.
4 participants
Description
Clicking a link inside a Quarto preview in Positron on Posit Workbench opened the page in a new browser tab instead of navigating inside the Viewer pane. Links are now classified against the origin the browser is on, so internal links stay in the pane.
Quarto's own preview server infers its origin from the request and sees localhost, while the browser is on the Workbench host. Comparing those two classified every internal link as external, on any deployment that serves a preview through a proxy. Comparing parsed origins also resolves relative hrefs, which the previous prefix comparison always treated as external.
Verified in Positron on a Posit Workbench deployment: a dashboard tab click stays in the Viewer pane, a relative in-document link stays in the pane, the toolbar "Open in Browser" still opens the system browser, and a genuinely external link still opens the system browser.
Checklist
I have (if applicable):
AI-assisted PR
Fixes #14865