Bug: clicking a file on the Media "Files" tab does nothing

[joestump-agent]

Context / Problem

On the Media page's Files tab, clicking a file attachment does nothing — it neither opens nor downloads the file.

Steps to reproduce

1. Go to Media → Files.
2. Click a file card / its filename link.

Expected vs actual

• Expected: the file opens or downloads.
• Actual: nothing happens.

Investigation notes (verified)

• File cards already render a download link: templates/gallery.html gallery_files_page uses <a class="media-file-name" href="{{mediaURL .ConversationID .RelPath}}" download="{{.OriginalName}}"> (the download attribute was added for issue Media/attachment UX: don't navigate the webview to raw files; styled error pages joestump/msgbrowse#161).
• The whole app is hx-boosted, so same-origin anchor clicks are intercepted by HTMX and swapped into #main-content. A boosted click on a link whose response is a raw binary (served by handleMedia, GET /media/{id}/{path...} in internal/web/media.go) would fail to swap and read as "nothing happens." Prime suspect — verify whether the anchor needs hx-boost="false" / hx-disable (or target="_blank") to bypass boosting, and whether handleMedia sets a Content-Disposition: attachment header.
• Also confirm mediaURL resolves correctly for the Files tab (images on the same page work, so the path helper itself is likely fine).

Proposed solution / Acceptance criteria

• Clicking a file on the Files tab reliably downloads (or opens) it in both browser and desktop-webview modes.
• Fix works for infinite-scroll continuation pages (handleGalleryItems → gallery_files_page).
• Non-stat-able / missing files still render without breaking the click for valid ones.

Relevant code

• internal/web/templates/gallery.html (gallery_files_page)
• internal/web/media.go (handleMedia, /media/{id}/{path...})
• internal/web/gallery.go (decorateFiles, handleGalleryItems)

[joestump-agent]

#18 merged: the Files-tab card link and the Images-tab "no preview" placeholder now carry hx-boost="false" with regression tests, and /media/... was verified to serve Content-Disposition: attachment correctly.

Leaving this open for now on the reviewer's caveat: those anchors were not inside any boosted container on main (boosting is per-container, not app-wide), so the merged change hardens the contract but may not be the causal fix for the reported symptom. If "clicking does nothing" is still reproducible, the next suspect is the desktop webview's download handling. The Media diagnosis work for #15 will re-verify this and close it if the symptom is gone.

---

Generated by Claude Code

[joestump-agent]

Re-verification landed in #26 (merged). Evidence-based verdict:

• PR Fix #4: keep Media file-download links out of htmx boosting #18's hx-boost="false" did not address the reported cause — confirmed the reviewer's suspicion: #main-content sits inside the un-boosted .drawer-content; only the toolbar title/nav/search and the sidebar are boosted, so the file anchors were never htmx-intercepted. (The attribute is harmless future-proofing and is kept.)
• File present → the web path cannot reproduce "click does nothing": native navigation returns 200 + Content-Disposition: attachment → a real download (TestMediaServesAttachment, TestWhatsAppMediaServing).
• File missing → the anchor hit a 404. Media: stat-gated image renderability + labeled placeholders for missing files #26 now makes that case degrade gracefully (labeled placeholder / inert chip instead of a dead click or broken image).

Keeping this open for the one path the server can't fix: desktop-webview (Wails v2) download interception, which needs a follow-up in cmd/msgbrowse-desktop. If the symptom was only ever seen in the browser, #26 resolves it and this can be closed — flagging for a maintainer call on whether the desktop follow-up warrants its own issue.

---

Generated by Claude Code