Loss of all image rendering in preview

[will-alma]

Version 3000.0.4 (1310)

As of approximately 17 hours ago the MacDown3000 preview pane lost all ability to render images from any source, via online link, local file link, or local server file link. All image containers render at the appropriate size, location, and any applied customization (shape, borders, etc) but the image itself cannot be rendered. Rendering from all sources were previously working properly.

Using HTML <img src=>

_Using markdown ! [ ] ( ) _

Tested all three source locations (local file, web, https:// link to local server file) with each with identical results.

[schuyler]

Investigation summary & requirements

Thanks for the detailed report — the "container lays out but the bits never load" symptom and the "broke ~17h ago with no app update" timing were both useful clues.

What I traced in the current codebase. Nothing in MacDown blocks image subresources today:

Layer	Setting	Blocks images?
App Transport Security	NSAllowsArbitraryLoads = true	No — http:// allowed
Preview CSP (MPPreviewContentSecurityPolicy)	img-src data: file: http: https:	No — every scheme allowed
WebResourceLoadDelegate willSendRequest:	Only rewrites MathJax.js; passes everything else through	No
WebPolicyDelegate nav policy	Only gates file:// navigations, not image subresource loads	No

Two facts that shape the conclusion. The preview CSP didn't exist when this was filed (it landed later, after 3000.0.6), so it can't be the original cause. And a static <img> failing from all sources at once, with no app update, points to an environment change — most likely the deprecated legacy WebView reacting to a macOS system update. ATS/CSP/network issues would each only affect a subset of sources, not all three.

Decision (with @schuyler): keep the fix small. A WKWebView migration — the only thing that would address a legacy-WebView/macOS-level failure — is out of scope for now. Instead, add regression coverage for the class of failure that is within the code's control (a future change silently dropping an image source), since that's exactly the #341 symptom.

Scope of the change:

• New MPImageRenderingTests asserting the full preview HTML preserves the <img> src for http, https, local-file, file://, and data: sources, and that the CSP img-src/media-src directives keep every scheme allowed.
• A tripwire comment above MPPreviewContentSecurityPolicy documenting that contract.

These are pipeline-level guards and cannot catch a failure inside the legacy WebView itself — the PR includes a manual testing plan for verifying the live preview on a Mac.

---

Generated by Claude Code

[schuyler]

Thanks for the detailed report and screenshots — the "container renders but the image never loads" detail is exactly the useful kind.

Some honesty about where this landed: I dug through the whole preview path and couldn't find anything in MacDown that blocks images. Web (http/https), file://, and data: image sources are all permitted, and nothing in the rendering or resource-loading code drops them. Combined with the most telling detail in your report — that it broke without an app update and hit all three sources at once — this points away from a MacDown code change and toward something in the environment, most likely a macOS update affecting the older preview engine MacDown uses.

To confirm that and find the right fix, a few questions would really help:

1. macOS version, and did macOS install an update around the time this started (~the day before you filed)?
2. Does it persist after quitting and relaunching MacDown, and after a reboot?
3. Does it still happen in a brand-new document with a single image, e.g. [test](https://www.gnu.org/graphics/heckert_gnu.transp.small.png)?
4. If you export to HTML or PDF (File → Export), do the images appear there? This tells us whether it's the live preview specifically or the rendering as a whole.
5. Does that same image URL load fine in Safari on the same machine?
6. Are you on the latest release (3000.0.6), or still on 3000.0.4? If you can update, does it change anything?

Answers to 1, 2, and 4 in particular will tell us whether this is the preview engine vs. macOS vs. something else, and whether a deeper fix (moving the preview to the modern WebKit engine) is warranted.

---

Generated by Claude Code