Make an image zoomable even when the feed didn't spell out where it lives

Tapping an image in a Ftrain article did nothing. The zoom affordance was
there, and the rendering path was the ordinary one -- the feed's own HTML, with
reader mode off -- but a tap went nowhere at all.

Tap detection works by wrapping every article image in a link to a scheme
nothing can navigate to, which the WebView then hands to
shouldOverrideUrlLoading. That href has to carry the complete image URL on its
own, so an image whose src was relative got no wrapper and no tap: better an
image that can't be zoomed, the reasoning went, than a link that goes nowhere.
Ftrain's <content:encoded> is entirely site-relative -- every image in it is
src="/art/uploads/..." -- so not one of them was zoomable.

That reasoning had an unexamined premise. The page itself resolves those srcs
perfectly well, against the base URL loadReaderHtml already hands
loadDataWithBaseURL: the article's own link. Resolving them the same way at
HTML-assembly time produces exactly the URL the WebView went and fetched, so
the wrapper can be built after all. Both reader surfaces now pass that base URL
down to the zoom pass. Where there genuinely is no base URL to resolve
against -- nothing else in the app loads reader HTML without one today -- the
old behavior stands and the image stays un-zoomable rather than acquiring a
dead link, and a data: or javascript: src is still refused however it was
reached, since the viewer could never open one.

This is why the report could only have come from a feed with reader mode off.
Reader mode never hits it: Readability rewrites every src to an absolute URL
before the extracted HTML reaches us, which is also why the same images zoom
fine the moment the feed's reader toggle is on.

TDD: site-relative and path-relative resolution, and the whole trip through
wrapReaderHtml, were written first against the unused parameter and went red on
assertion mismatches (3 of 38 in ImageZoomTest), green on the resolution
itself. The data:-src case was written at the same time and passed immediately
-- it pins existing behavior against the new code path rather than having
driven it.

Verified on the emulator against the reported article itself, subscribed live
from ftrain.com/feed.xml with reader mode off: on the previous build, a tap on
the header image left the screen byte-identical; on this one the same tap at
the same point opens the full-screen viewer.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018AwnALZL6bD4VBtATDVv3B

1 files changed, 32 insertions, 7 deletions

diff --git a/app/src/main/java/org/terst/feedreader/ui/ImageZoomLinks.kt b/app/src/main/java/org/terst/feedreader/ui/ImageZoomLinks.kt
index b83b600..d924c02 100644
--- a/app/src/main/java/org/terst/feedreader/ui/ImageZoomLinks.kt
+++ b/app/src/main/java/org/terst/feedreader/ui/ImageZoomLinks.kt
@@ -1,5 +1,7 @@
 package org.terst.feedreader.ui
 
+import java.net.URI
+
 // How a tap on an article image is noticed at all, and turned into a URL the viewer
 // (ImageZoom.kt) can open. Split from the viewer itself because this half runs at
 // HTML-assembly time, inside wrapReaderHtml -- it's reader-markup plumbing, not gestures.
@@ -35,7 +37,7 @@ private val imageFileExtensions = listOf(".jpg", ".jpeg", ".png", ".gif", ".webp
  * and wrapping it would swallow the tap that plays the video). Those are still zoomable when
  * the link points at an image file, which [zoomableImageTarget] handles on the other side.
  */
-fun linkifyImagesForZoom(html: String): String = buildString {
+fun linkifyImagesForZoom(html: String, baseUrl: String? = null): String = buildString {
     var copiedUpTo = 0
     var anchorDepth = 0
     for (tag in anchorOrImageTagRegex.findAll(html)) {
@@ -45,7 +47,7 @@ fun linkifyImagesForZoom(html: String): String = buildString {
             text.startsWith("<a", ignoreCase = true) -> anchorDepth++
             anchorDepth == 0 -> {
                 val src = imgSrcRegex.find(text)?.let { it.groupValues[1].ifEmpty { it.groupValues[2] } }
-                val href = src?.let { zoomHrefForSrc(it) }
+                val href = src?.let { zoomHrefForSrc(it, baseUrl) }
                 if (href != null) {
                     append(html, copiedUpTo, tag.range.first)
                     append("<a href=\"").append(href).append("\">").append(text).append("</a>")
@@ -57,17 +59,14 @@ fun linkifyImagesForZoom(html: String): String = buildString {
     append(html, copiedUpTo, html.length)
 }
 
-private fun zoomHrefForSrc(src: String): String? {
+private fun zoomHrefForSrc(src: String, baseUrl: String?): String? {
     val trimmed = src.trim()
     val absolute = when {
         // Protocol-relative (//host/path) is common in feed markup and resolves fine in the
         // page itself, but our scheme-prefixed href has to carry a complete URL on its own.
         trimmed.startsWith("//") -> "https:$trimmed"
         trimmed.startsWith("http://", ignoreCase = true) || trimmed.startsWith("https://", ignoreCase = true) -> trimmed
-        // Anything else (site-relative, data:, javascript:) is skipped rather than guessed at:
-        // a relative src resolves against the WebView's base URL, which a custom-scheme href
-        // can't reproduce, so wrapping it would only build a dead link.
-        else -> null
+        else -> resolvedAgainstBase(trimmed, baseUrl)
     } ?: return null
     // The src came out of a quoted attribute and goes straight back into one, already escaped
     // as the source wrote it. A raw quote or angle bracket could only arrive via a
@@ -76,6 +75,32 @@ private fun zoomHrefForSrc(src: String): String? {
 }
 
 /**
+ * What a relative src actually points at, or null if there's no way to tell or it isn't
+ * something the viewer could open.
+ *
+ * A feed's own HTML routinely keeps its images site-relative (Ftrain's <content:encoded> is
+ * entirely `<img src="/art/uploads/...">`), and that path is what the non-reader rendering
+ * shows verbatim -- reader mode never hits this because Readability rewrites every src to an
+ * absolute URL before we see it. The page resolves those against the base URL that
+ * loadReaderHtml hands loadDataWithBaseURL, which is the article's own link, so resolving them
+ * the same way here yields exactly the URL the WebView itself fetched. With no base URL there
+ * is still nothing to resolve against, and the image stays un-zoomable rather than getting a
+ * dead link.
+ */
+private fun resolvedAgainstBase(src: String, baseUrl: String?): String? {
+    if (src.isEmpty() || baseUrl.isNullOrBlank()) return null
+    // URI() rejects a src with a space or other illegal character in it rather than guessing,
+    // which is the right answer here too -- an un-zoomable image beats a dead link.
+    val resolved = runCatching { URI(baseUrl).resolve(src) }.getOrNull()
+    // data: and javascript: srcs are already absolute, so resolve() hands them straight back;
+    // only a real network URL is something Coil could ever open.
+    return when (resolved?.scheme?.lowercase()) {
+        "http", "https" -> resolved.toString()
+        else -> null
+    }
+}
+
+/**
  * The image a tapped URL should open full-screen, or null if it isn't an image at all.
  *
  * Covers both halves of the problem: links [linkifyImagesForZoom] built, and links the article