fix(export): local images render on Print/Export PDF (asset scheme + missing-image warning) (#1086) - #1088
Merged
Merged
Conversation
Local images rendered in the editor but showed a missing image on Export PDF / Print. resolveResources classified Tauri's asset scheme `https://asset.localhost/…` (emitted by convertFileSrc on newer macOS/WebKit and Windows, whitelisted in the CSP) as a remote URL because it starts with `https://`, and passed it through untouched — before the asset-aware resolveRelativePath ever ran. The off-screen print/PDF WKWebView has no asset:// handler, so the image never loaded. Classify asset URLs as local regardless of scheme (`isRemoteUrl(src) && !isAssetUrl(src)`) so they are inlined (single mode) or copied (folder mode). Scheme-agnostic: covers both `asset://localhost/` and `https://asset.localhost/`. Also unify the image-preview popup's relative-path detection on the shared mediaSecurity predicates (was a narrower local copy accepting only `./` and `assets/`) and add the editor NodeView's validateImagePath traversal guard, so a bare relative path like `evidence/page-1.png` previews consistently with how it renders inline. Regression tests cover asset-URL inlining/copying in both modes and bare-relative / parent-traversal handling in the preview popup.
Images that resolveResources can't inline are swapped for the "Image not found" placeholder in the print/PDF output. That substitution was silent (dev-only exportWarn). Log every offending path and raise a single count toast from both exportToPdfBrowser (Print) and exportToPdfNative (Export PDF) so the user knows the output is missing images. Adds exportImageWarning_one/_other across all 10 locales.
…1086) Cross-model audit (Codex) found isAssetUrl() missed the http://asset.localhost/ scheme that Tauri's convertFileSrc emits on Windows/WebView2. Without it, a Windows asset image URL stayed classified as remote (starts with http://) and passed through untouched instead of being inlined — the same missing-image bug the fix targets, on Windows. Add the http variant so asset classification is complete across platforms; no macOS impact.
The missing-image warning + asset-scheme changes pushed useExportOperations.ts and resourceResolver.ts past their frozen check:all file-size baselines. Extract warnMissingResources into exportResourceWarnings.ts, collapse the resolveResources call-site object literals, fold the two asset.localhost checks into one regex, and tighten comments. No behavior change; all export tests still green.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #1086
Problem
Local images rendered in the editor but showed the "Image not found" placeholder on Export PDF / Print, even when the file existed and the path was correct.
Root cause
resolveResourcesclassified Tauri's asset schemehttps://asset.localhost/…(emitted byconvertFileSrcon newer macOS/WebKit, whitelisted in the CSP and fully handled byisAssetUrl/resolveRelativePath) as remote — because it starts withhttps://— and passed it through untouched before the asset-aware resolver ran. The off-screen print/PDF WKWebView has noasset://handler, so the image never loaded. (The issue's suggested fixes #1 and #2 were already satisfied: inlining runs in the main window, andsourceFilePathis threaded through every export command.)Fix
isRemote: isRemoteUrl(src) && !isAssetUrl(src). Scheme-agnostic — coversasset://localhost/,https://asset.localhost/, and (Windows/WebView2)http://asset.localhost/. Covers inline + block images, single (PDF/Print) and folder (HTML) modes.exportImageWarning, added to all 10 locales) viawarnMissingResources.mediaSecuritypredicates +validateImagePathguard (issue fix refactor(popup): consolidate shared popup code and fix silent catches #4), so bare relative paths preview consistently with how they render inline.Testing
TDD (RED→GREEN) regression tests for asset-URL inlining across schemes/modes and bare-relative / traversal handling in the preview. Full
pnpm check:allgreen on the merge of this branch + #1087 (one unrelated flaky content-server watcher test needed a re-run).