Address issue #405: never use the document file as the preview base URL#456
Merged
Conversation
WebKit on macOS 26 can silently blank the preview when its file:// base resource is the real document file, based on metadata WebKit inspects but the editor does not (the execute bit set by sync clients, or stale TCC/provenance state on long-lived files). A new document renders fine, but reopening a saved file leaves the preview empty. Generalize previewSafeBaseURL: so the real document file is never handed to WebKit as the base resource. Whenever the base URL points at a real file, substitute a non-existent sentinel in the same directory. The base URL is only ever needed for the document's directory (relative resource resolution, MPLocalFilePathsInHTML, cache busting, and the MPURLSecurityPolicy scope check, which keys off the parent directory), so this leaves all of that unchanged while covering the broader blank-preview class beyond the execute-bit-only heuristic. Add unit tests covering regular files, executable files, directories, non-existent paths, non-file URLs, and nil, plus an opened-file lifecycle test asserting rendererBaseURL: never returns the real document file. Update the changelog to describe the generalized fix. Related to #405
Contributor
Code Coverage ReportCurrent Coverage: 60.57% Coverage Details (Summary) |
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
2 participants
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.
Summary
A new document previews fine, but opening a saved
.mdfile leaves the preview empty while the editor works. On macOS 26, WebKit silently refuses to load thefile://preview content when its base resource is the real document file, based on metadata WebKit inspects but the editor (which reads bytes viaNSDocument) does not — e.g. the execute bit set by sync clients like OneDrive (#431/#454), or stale TCC/provenance state carried by a file's inode across its history (#431). There's no signal in the document bytes, so there is no reliable runtime detector.This generalizes the previously execute-bit-only
previewSafeBaseURL:so the real document file is never handed to WebKit as the base resource. Whenever the base URL points at a real file, a non-existent sentinel in the same directory is substituted. The base URL is only ever needed for the document's directory — relative resource resolution,MPLocalFilePathsInHTML, cache busting, and theMPURLSecurityPolicyscope check (which keys off the parent directory) — so all of that is unchanged, while the broader blank-preview class is covered.Changes
MPDocument.m—previewSafeBaseURL:now substitutes the sentinel for any real file base URL (not just executable ones); directories, non-existent paths, and non-file URLs pass through. Updated the explanatory comment. Single-point change; both preview load paths already route through this method.MPDocumentIOTests.m— unit tests for regular file, executable file, directory, non-existent path, non-file URL, and nil.MPDocumentLifecycleTests.m— opened-file test assertingrendererBaseURL:never returns the real document file when afileURLis set.CHANGELOG.md— updated the entry to describe the generalized fix.Related Issue
Related to #405 (and the same root cause as #431).
Manual Testing Plan
On macOS 26 with a sync client (or any file that previously rendered blank on open):
.mdfile, close the window, reopen the file → the preview should now render (previously empty)..mdfile (chmod +x file.md) and open it → preview should render.[](image.png)alongside the file) → the image should still load, confirming relative resource resolution is unaffected by the sentinel base URL.Review Notes
MPURLSecurityPolicy.isExecutableOrAppBundleAtURL:is still used by the resource security checks, so it remains in use.