summaryrefslogtreecommitdiff
path: root/app/src/test/java/org/terst/feedreader/readability/ExtractionFailureTest.kt
diff options
context:
space:
mode:
authorPeter Stone <thepeterstone@gmail.com>2026-09-18 05:11:25 +0000
committerPeter Stone <thepeterstone@gmail.com>2026-09-18 05:12:31 +0000
commit05f3d13b11a560220771e8d351b77173532e0be0 (patch)
treed1aa536a7665d24644d1f0bd999e448e54a29a7d /app/src/test/java/org/terst/feedreader/readability/ExtractionFailureTest.kt
parentb5a96ad1d0a412c21159d6265e451f7c3aefc796 (diff)
Tap an article image to open it full-screen, with pinch/double-tap zoom
Article images could be looked at but never enlarged -- a photo or a chart in a feed was stuck at whatever size the reader column gave it. Tapping one now opens a full-screen viewer: pinch to zoom (up to 6x), double-tap to toggle between fitted and 3x, drag to pan while zoomed, and dismiss with back, the close button, or a swipe down. Detecting the tap is the whole difficulty. The reader is a WebView, and its JavaScript is off deliberately (untrusted article content), so no in-page script can notice a tap on an <img> and report it out. WebView's own built-in zoom isn't the answer either: pinching in the reader is already taken, on purpose, by the reader-font-size gesture, and page zoom scales the article's whole layout rather than giving an image the screen. So wrapReaderHtml now wraps every image that isn't already inside a link in a link to a scheme nothing can navigate to (feedreader-image:<url>), which WebView hands to shouldOverrideUrlLoading -- the interception point that already routes ordinary links and YouTube thumbnails. The new onImageTap callback opens ImageZoomDialog instead of following it. Images that already sit inside a link are left alone: ReaderExtractor's synthesized YouTube thumbnail is exactly that shape, and re-wrapping it would swallow the tap that plays the video. Those stay zoomable from the other side -- a link pointing straight at an image file is also treated as a zoom target, which additionally fixes WordPress's default "link to media file" markup sending a tap off to LinkReaderScreen to run Readability over a JPEG. The long-press-link handler strips the scheme back off, so the actions menu still offers the real image URL. The viewer is Compose + Coil (AsyncImage), matching what the article list's thumbnails already use, so a just-scrolled-past image usually comes straight from Coil's cache; zoom is a graphicsLayer transform, not a re-decode. Panning is bounded by where the image actually is rather than by the viewport -- ContentScale.Fit letterboxes anything that isn't the screen's aspect ratio, and bounding by the viewport would let a wide photo be dragged up into its own black bar. Coil reports the intrinsic size once decoded; until then the viewport is the fallback bound. TDD: the HTML rewriting (linkifyImagesForZoom), the tap-target decision (zoomableImageTarget), and the zoom/pan math (imageZoomScale, imageZoomDoubleTapScale, clampImagePanOffset, fittedImageSize) were all written test-first against stubs, red on assertion mismatches, green on the real implementations -- 26 new cases in ImageZoomTest, including three over wrapReaderHtml itself to pin the ordering that keeps the YouTube thumbnail's link intact. Gesture wiring and the dialog itself are Compose UI, untestable here for the same reason the rest of ui/ is. Coverage is unchanged: ui/ is excluded from the Jacoco metric by design.
Diffstat (limited to 'app/src/test/java/org/terst/feedreader/readability/ExtractionFailureTest.kt')
0 files changed, 0 insertions, 0 deletions