fix(desktop): make HTML artifacts directly openable - #5216
Conversation
liugddx
changed the title
Astro-Han
left a comment
Astro-Han
left a comment
There was a problem hiding this comment.
Result
NO-GO for exact commit da213246597f40360705099a5273f1c6033ef693: 1 P2 and 1 P3. I found no P0 or P1 in the reviewed paths.
P2 — the promised Finder fallback is not reachable for unreadable HTML previews
The PR description says it retains an explicit Finder fallback for unreadable previews. The HTML failure path does not preserve that behavior:
apps/desktop/src/renderer/features/workbar/tools/artifacts/artifact-preview.tsx:179-182,338-347renders the HTML read-failure action with theShow in Finderlabel.apps/desktop/src/renderer/features/workbar/tools/artifacts/artifact-pane.tsx:262-283,548-550,582-588routes that action throughartifacts.openPath.apps/desktop/src/main/runtime-host-artifacts-ipc-main.ts:94-105sends every HTML open request toshell.openPath; production injects it atapps/desktop/src/main/runtime-host-boot.ts:1637-1644. Only non-HTML artifacts useshowItemInFolder.- The failure copy still directs users to Finder in
apps/desktop/src/renderer/locales/artifact-copy.ts:110-118,146-154,182-190.
Thus, when an HTML preview is too large, deleted, or otherwise unreadable, the visible Show in Finder action launches the default application instead. There is no remaining renderer path that actually reveals the materialized HTML in Finder, contrary to the stated fallback contract.
Please keep separate Open and Show in Finder actions. The HTML failure card should use a Finder/reveal IPC operation (or an explicit action mode that forces showItemInFolder), while the successful HTML action continues to use shell.openPath.
P3 — HTML opener failure paths are not regression-tested
The new test at apps/desktop/src/main/__tests__/runtime-host-artifacts-ipc-main.test.ts:253-308 covers only successful HTML materialization and opening. It does not cover shell.openPath returning an error string, rejecting, materialization failure without invoking an opener, or the HTML failure CTA's Finder behavior. Existing Save As and non-HTML Finder tests do not cover these new paths.
Please add focused tests for the opener error and throw cases, assert no opener is called when materialization fails, and add a renderer regression for the HTML failure CTA.
The HTML path still goes through the existing main-process materialization, stream/byte validation, and path boundary. The sandboxed preview remains sandbox="allow-scripts" without same-origin, popups, or top-navigation permissions. I found no new path-containment, cross-session, or Host-protocol P0/P1 issue.
At review time, hosted package and test checks were still pending. git diff --check and the merge-tree check passed. Local build/typecheck and renderer architecture checks could not run because this checkout lacks a usable tsc and @babel/parser; a direct core visibility smoke passed. No real Electron/default-application smoke was available.
Automated review notice: This review was produced by an AI agent and is not a substitute for independent human review.
|
Addressed Astro-Han's P2/P3 review findings in 86eec55.
Verification:
|
|
Follow-up: the renderer regression is now kept inside the existing |
Astro-Han
left a comment
Astro-Han
left a comment
There was a problem hiding this comment.
Reviewed exact head c64a564ef4a553d094eb767212cfd835a6463a49.
The previously identified issues are resolved. The HTML preview failure action now uses a dedicated app:showArtifactInFolder path, while app:openArtifactPath remains the default-app opener. The preload bridge, Workbar adapter, and ArtifactPane keep “Open” and “Open in Finder” as separate actions. The new regression tests cover successful reveal, default-app opener errors/rejection, materialization failure without invoking an opener, and the HTML failure CTA.
I found no new P0–P3 issue on this head. Hosted test and package are successful; merge-tree and whitespace checks are clean. Local full build/typecheck/Electron smoke were not independently run because this checkout lacks a complete toolchain.
Automated review notice: This review was produced by an AI agent and is not a substitute for independent human review.
Astro-Han
left a comment
Astro-Han
left a comment
There was a problem hiding this comment.
Thanks for separating Open from Show in Finder. I independently checked c64a564ef, including the earlier review fixes. The supported flow addresses the reported problem without adding a localhost server, changing Browser file-URL admission, or introducing another Artifact authority. Both native actions continue through the existing Main materialization and validation path; the embedded preview retains sandbox="allow-scripts".
I rebuilt this exact head and passed 28 focused tests across Artifact IPC, Workbar services/renderer behavior and core visibility. I also rendered the actual ArtifactPane with production CSS in Electron in light and dark modes: tool-result HTML appears in the list, Open and Show in Finder reach separate service callbacks, and the unreadable-preview CTA invokes only reveal. The embedded iframe keeps its sandbox restriction, and no renderer errors were observed. This local UI fixture uses controlled Artifact services; it does not independently repeat the author's full Write-to-default-browser handoff.
No P0–P2 findings. There is one non-blocking P3 simplification suggestion inline: share the duplicated local error handling while keeping the two operations explicit. No general facade or additional controller is needed. Current test/package checks are green.
AI-assisted review and local verification with Codex.
中文
当前修复保留“打开”和“在 Finder 中显示”的不同语义，仍通过现有 Main Artifact 校验与物化路径，没有新增服务器、Browser 放行规则或权威。28 项测试及真实 Electron light/dark 的列表、菜单、失败 CTA 和 iframe sandbox 检查通过。UI 验证使用可控 Artifact 服务，未独立重跑作者的完整 Write→默认浏览器流程。无 P0–P2；仅建议合并两处局部重复错误处理，不增加通用门面层。
| } | ||
| } | ||
|
|
||
| async function showInFinder(artifactId: string) { |
There was a problem hiding this comment.
[P3] The separate Open and Show in Finder actions are correct, but this function duplicates the session-activity guard, result handling and catch/toast logic in openArtifact immediately above. A small local helper that accepts the selected service operation could keep that policy in one place and remove most of this duplication, while preserving the explicit menu/CTA actions and their separate IPC operations. No new service class or generic facade is needed. This is non-blocking.
Astro-Han
left a comment
Astro-Han
left a comment
There was a problem hiding this comment.
Thanks for making the HTML handoff usable and for fixing the Finder fallback. I would like to pause approval and settle one product decision before merging. My earlier review checked the implementation, but did not sufficiently question where the Open action should take the user.
I would like users to have an explicit choice between opening an HTML Artifact inside Maka and opening it externally. The existing sandboxed Artifact preview is a useful starting point for the in-app experience; the embedded Browser's file-URL restriction does not by itself mean that opening HTML should take the user out of Maka.
Keeping the in-app path matters beyond previewing: I would like to build toward annotating a generated page, giving feedback on a specific version, and asking Maka to improve it in the same task. That is a product direction, not a request to implement Annotation or introduce a speculative framework in this PR.
Could we first agree on the two entry points and their behavior here?
- An explicit in-app view, reusing the existing sandboxed Artifact surface where practical and keeping the connection to the Artifact and task.
- An explicit external-open action, with a label that makes leaving Maka clear. The label should match the actual handler:
shell.openPathuses the system default application, which is not guaranteed to be a browser.
Please keep the existing sandbox and path-validation boundaries. This discussion does not require relaxing file:// admission or adding a second preview implementation. If the existing preview already provides the intended in-app flow, making that choice discoverable may be enough.
I am withdrawing my approval while this interaction decision is discussed. The previous tests and implementation findings still stand; this is a product/design question, not a newly discovered code defect. Thanks for helping clarify it before the behavior becomes established.
中文
我想先暂停批准，讨论 HTML 的打开入口。之前的审查确认了实现，但没有充分判断用户点“打开”后应该留在 Maka 还是跳到外部，这点是我考虑不够。
我希望用户明确有两种选择：在应用内查看和交互，以及交给外部默认应用打开。已有沙箱 Artifact 预览可以作为应用内入口，不需要放开 file:// 或新建第二套预览。保留应用内路径，也为以后围绕具体版本做 Annotation、反馈和修改留出自然的工作流程；不要求这次实现标注或预建框架。
请先在这里确定两个入口的呈现和行为。外部入口的标签需要说清会离开 Maka，并与系统默认应用的实际行为一致。如果现有预览已经满足应用内路径，只需让这个选择更清晰，也可以是足够的方案。当前先撤回批准，待产品取舍收敛后再继续。
Withdrawing approval pending discussion of explicit in-app and external HTML opening choices, as explained in the follow-up review. Existing implementation verification remains valid.
2 participants
Problem
A real H5 workflow exposed misleading or unreliable local preview assumptions: an ad-hoc HTTP server could be reported as
runningeven when127.0.0.1was unreachable;file://navigation is intentionally rejected by the embedded Browser; Shell and Desktop Browser do not necessarily share a sandbox; and shellopenis not a reliable GUI handoff. These boundaries allowed an agent to claim a preview was started or opened before the user had a usable page.Issue #5213 records the full harness self-evaluation. This PR implements the supported Desktop Artifact handoff, but it does not resolve the remaining harness/platform gaps listed in that issue.
Change
Openaction for HTML Artifacts.shell.openPath). On macOS this normally opens the default browser.OpenandShow in Finderas separate operations: unreadable HTML previews and the explicit Finder action use a dedicated reveal IPC path backed byshell.showItemInFolder.file://security boundary; no localhost server or Browser admission change is introduced.This makes the supported H5 flow repeatable:
Write HTML → register HTML Artifact → Generated Files → Open → default application.Scope
Maka Desktop Artifact UI, Artifact visibility policy, and existing Artifact IPC only. The PR does not add a generic process supervisor, shared Shell/Browser networking, background-process health checks, capability preflight, or a platform-managed preview endpoint. Those remaining harness/platform gaps stay open in #5213.
Relates to #5213
Closes #5215
Related: #4267
Validation
Local checks on the latest review fix:
npm run typecheck --workspace apps/desktopnpm run check:architecture --workspace apps/desktopnpx knip --workspace apps/desktopnpm run build:test --workspace apps/desktopnode --test apps/desktop/dist/main/__tests__/runtime-host-artifacts-ipc-main.test.js apps/desktop/dist/main/__tests__/workbar-services-adapter.test.js(20/20)Maka Dev end-to-end verification of the successful HTML Artifact path:
Writeto create an interactive HTML file.生成文件 1.打开; clicking it launched Chrome Canary through the system-default-app path.Preview E2E Ready.Run interactionchanged the page toInteraction confirmedand4 of 4 confirmed.No Paseo, subagent, localhost server, or embedded Browser tool was used by the Maka task.