feedreader.git - FeeDreader — personal Android RSS reader

Age	Commit message (Collapse)	Author
38 hours	Make an image zoomable even when the feed didn't spell out where it lives	Peter Stone
	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
2026-10-23	Give YouTube's player a height, so the picture has somewhere to go	Peter Stone
	Peter, three builds running: audio plays, YouTube's title, controls and scrubber thumbnails all draw, and where the picture belongs there is a blank rectangle. None of my guesses were right. It is not the embed, not the window, and not the surface. It is layout. YouTube's player sizes itself with `body { position: absolute; height: 100% }`, and in this WebView percentage heights resolve against a containing block of zero height. Measured in the running app: window.innerHeight correctly reports 214, while 100vh and every percentage height resolve to 0. The body collapsed, the player chain under it collapsed, and the video element was laid out 380x0. That explains the whole symptom, including the part I kept failing to account for. The page, the chrome and the stream were all healthy -- the picture simply had nowhere to go, and what showed through the zero-height player was YouTube's own white <html> background. So the fix pins the player chain to the pixel height the page does know and dispatches a resize so YouTube's own code re-measures. Verified on a device, with the shipped code and nothing injected by hand: the video element goes 380x0 -> 380x214 and the video plays. Two things ruled out along the way, recorded so they are not retried: hardware-accelerating the dialog's window changed nothing, and nor did moving the player out of a dialog into an in-window overlay. An A/B against BrowserScreen looked decisive for the window and was not -- that WebView differs in layout too, and layout was the real variable. This treats the symptom. Why the viewport has no height is below this app, in WebView. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018AwnALZL6bD4VBtATDVv3B
2026-10-22	Name a title-less feed item by its own opening words	Peter Stone
	RSS requires an item to carry a title or a description, not both, and plenty of feeds take the second option. Mastodon's tag feeds are the case that surfaced it: every one of the 20 items in mastodon.social/tags/giftlink.rss has a description and no title at all, so subscribing to one produced a list of blank rows with nothing to read or tap. A post says what it is, it just says it in the body, so the item is now named by its own first sentence -- falling back to its opening words when the sentence runs long, and to its link when there are no words at all. Two details that the live feed taught rather than the fixture: Inline tags are removed without leaving a gap, and only block boundaries become a space. Mastodon splits a hashtag as `#<span>giftlink</span>` and a URL as `<span class="invisible">https:// </span><span>wapo.st/x</span>`, so turning every tag into a space tore both apart -- first pass produced "# HumaneRights # USPolitics" and "the loophole https:// wapo.". A full stop only ends a sentence when whitespace or the end of the text follows it, or the dot in "wapo.st/abc" ends it instead -- which is how that same title got cut at "https://wapo.". It also skips an opening fragment shorter than 20 characters: naming an article "Wow." helps nobody. Deliberately free of android.text.Html, unlike the parser's existing entity decoding -- that pulls in the framework, which is why FeedParser has no unit tests. This part does, 22 of them. Verified on a device against the live feed: 20 items, 0 blank titles, URLs and hashtags intact. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018AwnALZL6bD4VBtATDVv3B
2026-10-22	Hardware-accelerate the video dialog's own window	Peter Stone
	Peter, on the referrer build: the player "plays and shows controls, with a white screen instead of video. The scrubber thumbnails pop up, but the main playback is blank white." His screenshot shows YouTube's title, gear, play button, timecode and progress bar all drawn correctly over a blank area. That narrows it a long way. Everything the page renders -- chrome, gradients, the storyboard images behind the scrubber -- composites fine, so the renderer is healthy and the embed is right. The one thing missing is the only thing that does not come from the page: video is composited from a separate surface, and that needs the window it sits in to be hardware accelerated. The player is a Dialog, which is its own Window. The activity declares android:hardwareAccelerated, but that does not carry to a Window a dialog creates for itself, so the flag is now set on it explicitly. No new logic, so nothing new to unit-test: the URL and referrer this loads are unchanged and still covered by YouTubeLinksTest. It is a property of the window the existing WebView lives in. Unverified here, and this emulator cannot settle it: it has no working video path at all in a WebView. It hard-crashed the AVD twice on a plain <video>, and with software decoding forced it survives but renders a broken-media placeholder rather than a picture. Everything up to display is confirmed on-device; display is not. If the picture is still missing, this rules the window out and the remaining suspect is the surface itself, which means taking the player out of a floating window entirely. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018AwnALZL6bD4VBtATDVv3B
2026-10-21	Play the YouTube embed with a referrer instead of in an iframe	Peter Stone
	Peter, on the previous build: "the inline player now plays the audio but the video is a black screen." So Error 153 is gone and the stream is decoding -- what is left is a display problem. The iframe was not needed in the first place. A `Referer` header alone satisfies the embed, which means the player can be the WebView's own ordinary top-level document again. That drops two constructs the last build added: a `loadDataWithBaseURL` page, whose origin is synthetic, and a cross-origin subframe inside it. Both have a history of rendering video oddly in WebView, and the black screen appeared with them. Measured on an Android user agent -- no referrer: Error 153; `&origin=` in the query: Error 153; inside an iframe: plays; with a `Referer` header: plays. The referrer is a constant on a reserved `.invalid` domain rather than the article's URL, so YouTube learns which app asked and nothing about what is being read -- the same reason the nocookie domain is used. Confirmed in the app's own WebView: the embed loads with no error, 854x480, readyState 4, playing. NOT confirmed: that a picture now reaches the screen. This emulator cannot render video in a WebView at all -- it hard-crashed the AVD twice, including on a plain <video> in an ordinary non-dialog WebView -- so the one thing that matters here can only be checked on real hardware. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018AwnALZL6bD4VBtATDVv3B
2026-10-21	Fix stray promo headers, site-URL subscribing, and YouTube playback	Peter Stone
	Three reported bugs. "West Hawaii today articles get a bunch of stray Trending headers." The publisher's widget platform injects promo blocks between the real paragraphs, inside the article's own container, so every structural signal tells Readability they belong. What survives is a heading labelling nothing, because the links under it are filled in by a script that never runs in the reader. Confirmed on 9 of the 12 articles in that feed, two each. Blocks marked `data-mrf-recirculation` are now removed -- the attribute says what the block is for in the widget platform's own words, which is a better signal than the word "Trending", since an article may legitimately discuss what is trending. Nothing longer than a label and a few headlines is ever removed. Also applied to already-cached articles, in place rather than by discarding them: the article was fine, only the litter has to go. "Can't subscribe to heathercoxrichardson.substack.com." Adding a feed handed whatever URL it was given straight to the XML parser, so a site's home page -- the only URL a reader can actually see and copy -- failed on the root element. That page advertises its feed the way sites have since 2002, in a <link rel="alternate"> in the head. It is now read, resolved against the page, and fetched. Only what the page declares: guessing /feed and /rss would add a burst of 404s to every failed add and eventually subscribe somebody to the wrong thing. "YouTube play is misconfigured." It was, and YouTube said so: the player dialog loaded the embed as its own top-level document, which answers with "Video player configuration error -- Error 153". An embed has to be embedded. It now sits in an iframe on a minimal host page. Measured in the app's own WebView: top-level, no requests for the video stream and the error on screen; framed, the stream loads and there is no error. "Long click on YouTube placeholder should open the URL directly." It does now. Worth recording why this is not simply the link's href: for an image inside a link, WebView's hit test reports the image's URL, so a long-press on the thumbnail arrives as the i.ytimg.com JPEG. The video id is resolved out of that. Verified on a device for all four: the Substack site URL adds "Letters from an American" and fetches 20 articles; a West Hawaii Today article extracts with no Trending headers and its body intact; the video plays; and a long-press reaches the YouTube app. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018AwnALZL6bD4VBtATDVv3B
2026-10-16	Render an article's maths instead of showing its TeX source	Peter Stone
	Reported against lcamtuf's Substack ("we should render tex", blog.coredump.cx/p/yours-truly): reader mode showed raw "\(p = \text{...}\)" where equations should be. What the page actually ships is the TeX SOURCE, as text, inside a "latex-rendered" div -- Substack renders it in the browser with its own script, which never runs here. Readability keeps that text verbatim (it strips the class, not the text), so nothing was being discarded during extraction and no amount of extraction-side repair would have helped: there was simply never any rendered markup to keep. So render it during extraction, where JavaScript is already running for Readability's sake. KaTeX (vendored in assets, never fetched -- this runs against untrusted third-party pages) converts each expression to MathML before Readability sees the document, and the reader WebView renders that natively. The reader keeps JavaScript OFF, as it must, and needs no stylesheet, webfont or script of KaTeX's; the only reader-side change is containing a wide equation so it scrolls within its own box instead of dragging the whole article sideways. Two details worth knowing: - KaTeX refuses {align} outside display mode, and Substack wraps display maths in INLINE delimiters (a block-styled span does the centring), so a mode that renders nothing is retried in the other one. An expression neither mode can render is left as source -- no worse than before. - The reported article came with "extractedContent cached: true", so the raw source was already on disk and every open read it back. Recognised and dropped on read (same mechanism as the cached consent notice), which re-extracts the article the next time it is opened. APK grows by ~90KB: the vendored katex.min.js (267KB) compresses to 91KB in the APK. No new permissions, no schema change, no new JS-enabled surface. Verified on the emulator against the live article: stale raw-TeX cache discarded, article re-extracted, all four equations rendered, and a wide align block scrolls inside itself.
2026-10-12	Stop reader mode passing a site's cookie notice off as the article	Peter Stone
	Reported live: reader mode on a New Republic feature showed nothing but the cookie disclaimer, and had cached it. Reproduced outside the app by running ReaderExtractor's own injected script (Readability.js and all) against the real page. With the article body present, extraction is perfect. With the body absent from the DOM at the moment the script runs, Readability's first pass -- which discards "unlikely candidates", and the Didomi banner's class is didomi-notice-banner -- comes back under its own 500-character threshold, so it retries with that stripping switched off. The banner's single paragraph is 510 characters, i.e. just over the threshold, so it comes back as the article with the right title attached. Nothing on the Kotlin side looked at that. Any non-blank content counted as ExtractionResult.Success, was written to articles.extractedContent, and was never reconsidered -- so one bad load became a permanent cookie disclaimer, which is the "extractedContent cached: true" in the report. ConsentNotice recognises such a result: a hard plain-text length cap first (nothing long is ever rejected, however much consent boilerplate it quotes), then either a known CMP container id -- Readability strips classes but keeps ids -- or two or more distinct consent phrases. The accept/retry/give-up decision moves out of the WebView callback into decideEvalOutcome so it can be tested without a device. A consent notice is now "not ready yet", which routes it into the retry the extractor already does for an empty result; if it survives all six attempts that is what the page serves, and it fails as ExtractionFailure.ConsentInterstitial rather than being accepted. A fixed extractor cannot repair what is already on disk, so loadCachedExtraction drops a cached notice on read and re-extracts, in both ReaderScreen and LinkReaderScreen. No schema change: the repair happens when the article is next opened. Reader mode is still never turned on heuristically -- replacing a discarded notice does not flip it. The bug report now also carries the last extraction error, without which a report about bad reader content cannot say whether extraction failed. Tests: 59 -> 78. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018AwnALZL6bD4VBtATDVv3B
2026-09-29	Reflow reader text live while pinching, and let a zoomed image pan	Peter Stone
	Pinching in the reader used to scale the whole WebView like a photo and snap back to the real font size on release. It now drives WebSettings.textZoom as the fingers move, so the text itself resizes and reflows during the gesture with nothing to snap back from; images and margins stay put. The reload at the new saved size is what returns textZoom to 100%, so the two never overlap -- and loading reader HTML now goes through ReaderWebView.loadReaderHtml, which does both together, so a future load site can't forget the reset. Reader view for a tapped link now honors the saved font size and the same pinch gesture, instead of always rendering at the 18px default. A zoomed image can be panned again. The viewer computed its pan bounds from values captured when the dialog first composed -- an empty viewport around a not-yet-decoded image -- because a pointerInput(Unit) block keeps the lambda it was created with. Those bounds allowed exactly one offset, 0, so zooming worked and dragging did nothing. The whole pinch/pan step is now one pure function the gesture callback calls with values it reads fresh each time.
2026-09-20	Fix intermittent extraction failures, and stop them being silent	Peter Stone
	Bug report: extraction failed on one 1500days.com article while others worked. It is not that article. Extraction was racing the page load, and the report could say nothing more because the app discarded the reason. Two separate defects. 1. The race. onPageFinished fires before the page has finished loading — observed at progress=25 on this article — and the extraction script was injected there. Sometimes the DOM is far enough along; sometimes evaluateJavascript hands back a bare "null" because the document is still being replaced. Measured against the reported URL: 4 successes in 6 attempts before, 10 in 10 after. An unusable result is no longer final. A null or empty-content result is retried (6 attempts, 500ms apart, well inside the existing 25s timeout); a Readability error still fails immediately, since retrying will not change what the parser thinks of the markup. 2. The silence. ReaderScreen did `extracted?.content?.let { }`, so every failure — dead host, HTTP error, timeout, parser throw — arrived as the same null and was dropped. The reader just kept showing raw feed content. The only way a failure ever surfaced was the user noticing. extractResult() now returns a typed ExtractionFailure carrying the reason; ReaderScreen logs the diagnostic and shows the user a short explanation. Also replaced a dead error callback. The only override was the four-argument onReceivedError, which Android stopped calling at API 23; minSdk is 26, so it never fired on any supported device. A failed load therefore invoked nothing and hung for the full 25 seconds before surfacing as an indistinguishable null. Now overrides the request/error and onReceivedHttpError forms Android actually calls, both filtered to the main frame so a 404'd tracker cannot abort an article that renders fine. The instrumented test does NOT reproduce the race and says so in its own docstring: a MockWebServer page finishes loading before onPageFinished fires, and slow subresources do not help because WebView waits for them. It is kept as a reliability guard over repeated back-to-back extractions. The race was verified by hand against the live URL. 47 unit tests, 1 instrumented test, both green.
2026-09-18	Tap an article image to open it full-screen, with pinch/double-tap zoom	Peter Stone
	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.
2026-09-15	Support pinch-to-zoom for reader text size in the article view	Peter Stone
	Pinching in ReaderScreen's article WebView now adjusts the same persisted reader font size the Settings slider controls, instead of doing nothing (WebView's own page zoom was never enabled, so a pinch previously had no effect at all). A ScaleGestureDetector is fed through setOnTouchListener, which always returns false so it never consumes the touch -- WebView's existing one-finger scrolling, link taps and long-press-link handling are unaffected, since ScaleGestureDetector only fires once a second pointer is down. During the gesture the WebView is scaled live via View.scaleX/ scaleY for immediate visual feedback; at gesture end the scale resets to 1x and the computed, clamped font size is persisted, which drives ReaderScreen's existing content-reload-on-fontSizePx-change path to re-render the actual HTML at the new size. TDD: pinchZoomFontSizePx (the pure scale-factor -> clamped-px calculation) was written test-first, red on a TODO() stub, green on the real implementation -- covered by SettingsTest. newReaderWebView grew from 6 to 8 parameters to carry the new gesture hooks, which pushed it over detekt's LongParameterList threshold; bundled all of its callbacks into a ReaderWebViewCallbacks data class rather than baselining past it, updating both call sites (ReaderScreen, LinkReaderScreen). ReaderContent gained no new parameter -- it now independently remembers its own Settings instance to persist the pinch-committed size, matching how it already remembers its own db and scope rather than threading them from ReaderScreen. LinkReaderScreen's WebView is untouched: it doesn't read the reader font size setting at all today, so wiring pinch-zoom there would be a separate, unrelated fix.
2026-08-31	Add reader font size setting, rewrite paywall-avoidance settings copy	Peter Stone
	Font size was hardcoded at 18px in ReaderWebView's injected CSS. Added a DataStore-backed setting (Settings.readerFontSizePx, 14-28px range) with a slider in Settings, threaded through ReaderScreen/ReaderContent into wrapReaderHtml. The reload-tracking key in ReaderContent's AndroidView now includes font size alongside content, so changing it and returning to an already-open article picks up the new size without reloading on every unrelated recomposition (matches the existing comment there about avoiding scroll-position jank). Rewrote the Settings screen's paywall note -- it read as defensive throat-clearing about what the app won't do. Restated as what it's actually for: avoiding tracking, manipulation, and junk fees, with reader mode pulling up anything findable by search anyway. Regenerated the detekt baseline: ReaderContent's pre-existing LongMethod/LongParameterList/CyclomaticComplexMethod findings are keyed by exact function signature text, and adding the fontSizePx parameter changed that text, invalidating the old baseline entries. The underlying debt (a 300+ line, 9-now-10-parameter composable) predates this change and isn't what this commit is about. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018AwnALZL6bD4VBtATDVv3B
2026-08-24	Document the bug-report clipboard tool as intentional, not unfinished	Peter Stone
	An audit flagged it as looking half-built (builds a full diagnostic report but has no submission endpoint). Confirmed intentional: no backend exists to submit to on this single-user app, and the real destination is pasting it into a message during the normal hands-on-testing workflow. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017GMEkHeqKz6FLkmizowBTK
2026-08-24	Remove 3 confirmed-dead DAO methods	Peter Stone
	ArticleDao.delete(article) -- superseded by deleteUnsavedByFeed. ArticleDao.markAllReadForFeed -- no "mark all read for this feed" UI action exists; superseded by the id-list-based markReadBatchChunked. FilterRuleDao.getAll() -- every caller uses the Flow-returning observeAll() instead. Re-verified all three have zero callers beyond their own declaration before removing. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017GMEkHeqKz6FLkmizowBTK
2026-08-24	Let filter rules be scoped to one feed; fix coverage-gate report path bug	Peter Stone
	The data model and FilterRuleEngine already supported a per-feed scope (FilterRuleEntity.feedId), but Settings' "Add rule" form never let a user set it -- only a hardcoded migration had ever created one. Add a FeedScopePicker so a rule can target "All feeds" (unchanged default) or one specific feed, and show each existing rule's scope in the list. Added the first real unit tests in this repo (FilterRuleEngineTest), covering global vs. feed-scoped matching and mute-wins-over-highlight priority -- the exact behavior this UI gap left unexercised outside one migration-seeded row. First real jacoco coverage number: 2.31%. While verifying, found the pre-commit hook's coverage step was silently a no-op: it pointed at app/build/reports/jacoco/report.xml, but the jacoco setup that landed here uses the standard Gradle JacocoReport task, which writes to reports/jacoco/jacocoTestReport/jacocoTestReport.xml instead. Fixed the path so the gate actually reads real numbers now. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017GMEkHeqKz6FLkmizowBTK
2026-08-24	Pre-extract reader-mode content during feed fetch, not on article open	Peter Stone
	Feeds like West Hawaii Today need Readability to strip a paywall/ boilerplate wrapper, and that extraction was happening lazily the first time an article was opened -- a hidden WebView load + JS eval that left the reader sitting on a spinner. Do it for new articles from reader-mode feeds right inside FeedFetchWorker.fetchOne instead, so it's already cached (both on the launch fetch and the 5am morning fetch) by the time the article is actually opened. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017GMEkHeqKz6FLkmizowBTK
2026-08-23	Restore scroll position within an article on Next/Previous	Peter Stone
	Next/Previous replaces this screen's own back-stack entry with a fresh one for the neighboring article, which recreates the WebView from scratch -- going back to an article you'd been partway through always landed you back at the top. Tracks each article's scroll offset in an in-memory, process-lifetime map (ReaderScrollPositions) as the WebView scrolls, and restores it once the freshly-loaded page finishes laying out.
2026-08-23	Preserve scroll position when the article list changes underneath you	Peter Stone
	A background fetch (the 5am alarm or the refresh button) inserting new articles above the current viewport left LazyColumn pointing at the same numeric index, which after the insert resolves to a different (newer) article -- the visible list silently jumped forward instead of staying where you were reading. Re-anchors to the same article by id at whatever index it now sits at, restoring the exact scroll offset too.
2026-08-22	Restore the 5am morning-fetch alarm	Peter Stone
	Reverts part of the previous commit: the explicit refresh button and fetch-on-launch stay, but the user still wants the background 5am alarm so articles are fresh before the app is opened, not just the periodic hourly WorkManager job.
2026-08-22	Mute emptywheel's recurring "Fridays with Nicole Sandler" series	Peter Stone
	Reported via the in-app bug report against a specific numbered installment (-111). Seeds a MUTE filter rule scoped to the emptywheel feed rather than requiring it be added by hand in Settings, matching this file's existing pattern of shipping known personal-data fixes as migrations.
2026-08-22	Replace background auto-refresh with fetch-on-launch + explicit button	Peter Stone
	Periodic hourly WorkManager fetches and the 5am exact-alarm morning fetch both refreshed without any visible trigger, which surprised the user more than it helped. Refreshing now only ever happens on a fresh app launch (MainActivity.onCreate) or an explicit tap of the new refresh button on the Unread/Older screens' top bar (wired to the fetch-status state that was already being computed there but never rendered). Drops MorningFetchReceiver entirely along with its exact-alarm permission and boot receiver.
2026-08-22	Keep a just-read article visible (and Previous-reachable) until the next fetch	Peter Stone
	The Unread/Older views are live Room Flow queries filtered on isRead = 0, so marking an article read (which only happens on Next/Previous, not on open) makes it vanish from the list the instant Room re-emits -- mid-scroll, or from underneath the reader's own Previous button, which re-queries this same flow to find its neighbors. Concretely: Next from C to D marks C read and prunes it from the live list; Previous from D then can't find C anymore, and jumps past it to whatever was unread before C. A misclick or the in-flight prune could cost you the article you meant to keep reading. Adds ArticleEntity.readAt (set whenever isRead flips true, cleared on explicit "mark unread"); observeUnread/observeOlderUnread now match "isRead = 0 OR readAt >= sinceFetch", where sinceFetch is Settings.lastFetchAt -- the same durable signal the new-articles snackbar already uses. A read article now lingers (shown dimmed via the existing showReadState styling) until the next real fetch actually completes, not the next DB write, and Previous/Next read from the same still-inclusive query so stepping back to what you just read finds it right where it was.
2026-08-22	BrowserScreen: don't accept third-party cookies	Peter Stone
	This screen exists so a site's own first-party login session cookie survives into the reader's later extraction requests -- that's all the login-persistence feature needs. Third-party cookies are for cross-site trackers embedded in whatever page is loaded here, which this feature has no use for and which only adds tracking surface shared with every other WebView in the app.
2026-08-22	Add a 5am morning-fetch alarm so articles are fresh before you open the app	Peter Stone
	FeedFetchWorker's periodic 60-minute WorkManager job can (and does) get silently deferred for hours by Doze on an idle overnight device. An exact alarm (setExactAndAllowWhileIdle) wakes the device at a fixed 5am to run a fetch, without requesting the much broader "ignore battery optimizations" exemption -- battery optimization stays on otherwise, just this one daily wake-up. Android 12+ requires a one-time user grant for exact alarms (no in-app permission dialog); MainActivity requests it via Settings if not already granted, tracked across rotation via savedInstanceState so a config change doesn't re-trigger the Settings screen. The alarm also gets re-armed on BOOT_COMPLETED, since AlarmManager alarms don't survive a device restart on their own.
2026-08-22	Encrypt the Stash API key at rest	Peter Stone
	The key is a bearer credential for the user's own Stash server, sent as X-API-Key on every request -- previously stored in plain DataStore preferences, recoverable in cleartext from a rooted device, an unlocked-bootloader device, or a local backup/extraction tool. Now stored via EncryptedSharedPreferences (Android Keystore-backed AES-256). An existing key is migrated from the old plaintext location once, on first read, then the plaintext copy is cleared.
2026-08-22	Concurrent feed fetching with durable fetch-result tracking	Peter Stone
	Feeds are fetched with bounded concurrency (semaphore of 8) instead of strictly sequentially -- with 100+ subscriptions, one slow/stalling server no longer delays every feed queued behind it. A process-local mutex prevents the periodic and manual/alarm-triggered one-time fetches (two different WorkManager unique-work names, so its own dedup doesn't cover this) from ever running concurrently and racing writes to the same feed rows. Settings.recordFetchResult persists lastFetchAt/lastFetchNewArticles on every run, not derived from WorkInfo.State -- a PeriodicWorkRequest cycles back to ENQUEUED after every successful run and never reaches SUCCEEDED, so anything watching for that only ever saw manual fetches. ArticleListScreen surfaces this as a "N new articles" snackbar (acknowledged durably, so returning to the screen doesn't re-show it) and computes live "Checking feed X of Y" progress from the worker's tagged WorkInfo, scoped to the Unread/Older views that actually aggregate every subscription.
2026-08-22	v9: batch of feed URL fixes from July 31 triage; dedupe rename-and-reassign	Peter Stone
	Live triage pass over every subscription showing "Last fetch failed." Host-substring LIKE matching, not exact-string like v6-v8, since the exact previously-stored URL for most of these wasn't known ahead of time. Also extracts the repeated "rename a feed's id, reassign its articles, don't let a failure abort the migration transaction" dance (duplicated inline in v6/v7) into one renameFeedSafely helper used by both those and the new v9 migration.
2026-08-22	Fix reader rotation bug: replace-nav instead of a swipe-queue snapshot	Peter Stone
	The reader used to snapshot the article-id order of its list ONCE at entry and page a HorizontalPager across that fixed queue. Two real bugs traced back to one root cause: the snapshot lived in plain remember state that did NOT survive an orientation change, while the pager's own page index did -- rotating mid-session left the index pointing into a freshly re-fetched (and by then shorter, since paging past an article marks it read and drops it from the Unread query) list, landing on a different article than the one actually being read. Back was confusing for the same reason: it always returned to wherever the ORIGINAL initialArticleId pointed, not wherever the pager had since scrolled to. Fixed by not having a separate queue/index at all: each Next/Previous now replaces this screen's own back-stack entry with a fresh navigation to the neighboring article's id (MainActivity wires onNavigateToArticle with the same popUpTo-replace pattern LinkReaderScreen already uses for its own link chain). "Which article is showing" is now the nav route argument itself -- Android's own Saved State mechanism, not custom state that can drift out of sync with it -- and the back stack is always exactly [list, one reader entry] no matter how many articles were paged through.
2026-08-22	Feed writes: bulk OPML upsert, targeted fetch-result update, shared toggle	Peter Stone
	- AddFeedScreen: OPML import no longer crashes the app on a non-XML/corrupt file (try/catch around the whole import). Bulk upsertAll() instead of a per-feed getById()+upsert() loop -- 2N sequential DB round-trips for N feeds otherwise, real cost at 100+ feed subscription lists. - FeedDao.updateFetchResult only writes the columns a fetch actually produces, instead of a full-row @Update built from a feed snapshot read before a (possibly slow) network round-trip -- the old path could silently revert a readerModeEnabled/folder edit made via FeedListScreen while that feed's fetch was still in flight. - setReaderModeEnabled(feed, enabled) persists the toggle and returns the exact confirmation text, shared by FeedListScreen's per-row toggle and ReaderScreen's toggleFeedReaderMode -- previously two independently-typed copies of the same snackbar message.
2026-08-22	In-app YouTube playback, shared ConfirmDialog, hardened link handling	Peter Stone
	- ReaderWebView/LinkReaderScreen/ReaderScreen: tapping a YouTube link inside an article now opens an in-app player (youtube-nocookie.com, JS scoped to just that dialog) instead of handing off to the YouTube app/browser. Falls back to external-open when a confident video ID can't be extracted (playlist/channel links). - A subframe (ad/embed iframe) auto-navigating is now blocked outright instead of being treated like a real link tap -- it fired the exact same callback as a user tap, with no interaction required. - wrapReaderHtml can now show a fallback hero image + date when the feed's own body HTML has no image of its own. - ConfirmDialog: the generic "confirm before doing something irreversible" dialog shape was independently rebuilt from scratch at FeedListScreen's unsubscribe and ArticleListScreen's mark-read-from- here confirmations. Both now share one composable; the latter also chunks its batch update (markReadBatchChunked) so a long-unread feed can't exceed SQLite's per-statement bound-variable limit.
2026-08-22	Pre-compile filter rules instead of re-lowercasing per article per emission	Peter Stone
	ArticleListScreen calls evaluate() once per visible article against the same rule set, re-run on essentially any read-state change to any article in the list. With a couple hundred articles and a handful of rules, calling pattern.lowercase() inside the old per-article evaluate() was thousands of redundant String allocations of the same small set of strings.
2026-08-22	Require explicit tap before ShareReceiverActivity saves anything	Peter Stone
	This activity is exported (any installed app can target it directly with an ACTION_SEND intent, not just via the system share sheet). Starting extraction/Stash-save immediately on launch meant any other app could silently make this one fetch+JS-render an arbitrary URL and archive it to the user's own Stash server with zero user interaction. A tap is now the only thing standing between "another app sent an intent" and "real network work happens." Also switches to the shared saveArticleToStash helper while touching this same code path.
2026-08-22	Adopt shared saveArticleToStash in ReaderScreen and LinkReaderScreen	Peter Stone
	Replaces the 4 remaining copy-pasted StashClient-and-branch call sites (ReaderScreen x2, LinkReaderScreen x2) with the shared helper added in the previous commit.
2026-08-22	Extract shared saveArticleToStash helper (dedupe 5 copies)	Peter Stone
	The build-a-StashClient-and-branch-on-the-result dance was independently copy-pasted at 5 call sites (ShareReceiverActivity, ReaderScreen x2, LinkReaderScreen x2). StashSaveOutcome carries the exact snackbar text plus the artifact id, as a sealed class so a caller that cares about the Saved/AlreadySaved distinction can still pattern-match instead of parsing the message back apart. Not yet adopted at any call site -- follow-up commits switch each one over.
2026-08-22	StashClient: cancellable requests, longer sync timeout, defensive parsing	Peter Stone
	Uses the new Call.await() instead of a thread-blocking execute(). The sync=true save endpoint can take up to ~30s (server-side extract + summary), longer than the shared client's stock 10s read timeout -- overridden per-call so feed fetches don't inherit a 35s timeout they don't need. A 409 (duplicate) is authoritative from the status code alone; a body that doesn't match DuplicateErrorResponse's exact shape no longer downgrades a real "already saved" into a misleading "save failed".
2026-08-22	Harden extraction WebView, cache Readability.js, sharpen YouTube thumbs	Peter Stone
	- Cache the ~90KB Readability.js asset read (identical every time) instead of a disk read + UTF-8 decode on the main thread for every single extraction. - Lock down allowFileAccess/allowContentAccess/allowUniversalAccess: this WebView runs full JS against any article link, feed URL, or (via ShareReceiverActivity) any URL another app hands it -- no legitimate reason to ever load file://. - hq720 thumbnail instead of hqdefault (a letterboxed 4:3 crop). - Validate frameSrc is actually http(s) before using it verbatim as a fallback link -- it's attacker-controlled article content that only had to match a substring filter, not the strict video-ID regex, so a crafted file://, content://, or intent:// src couldn't ride along into an ACTION_VIEW intent or a JS-enabled WebView.loadUrl.
2026-08-22	Fix Atom feeds crashing the whole parse on xhtml content/summary	Peter Stone
	<content type="xhtml">/<summary type="xhtml"> wrap real nested markup, which XmlPullParser's nextText() can't handle (it requires a text-only element) -- it threw and aborted parsing of the entire feed over one xhtml-typed field. Walks and reconstructs the inner markup manually instead, tracking depth against the parser's own getDepth().
2026-08-22	Add a cancellable OkHttp Call.await() extension	Peter Stone
	execute() blocks the calling thread and ignores the coroutine it runs in -- if that coroutine is cancelled (a screen torn down mid-save, a WorkManager-stopped fetch), the network call keeps running to completion regardless, tying up a thread/socket for nothing. enqueue() plus invokeOnCancellation actually aborts the in-flight HTTP call.
2026-07-30	Merge Ars Technica's split .post-content blocks before Readability scores them	Peter Stone
	Ars splits a longer article's body across multiple sibling .post-content.post-content-double divs (with a mid-content ad rail between them) instead of one continuous container. Readability scores each as an independent candidate and keeps only the highest-scoring one, silently dropping the rest -- confirmed live on "Reaction wheel failures leave Swift rescue mission spinning in orbit", which lost its first 7 paragraphs (lede through the reaction-wheel explainer). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017Zwte3cyUJFUVycc3sDmjM
2026-07-30	Clamp WordPress caption wrappers so inline images stay in-column	Peter Stone
	img { max-width: 100% } only bounded the <img> itself; a WordPress <figure class="wp-caption" style="width: 448px"> wrapper sized for the source site's column was left unconstrained, so the wrapper (and the image filling it) overflowed the reader's own narrower column. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017Zwte3cyUJFUVycc3sDmjM
2026-07-25	Fix BrowserScreen back button: step through page history before closing	Peter Stone
	Reasoned through the code rather than reproducing live (per explicit instruction). An earlier change made back always close the whole browser screen in one press, regardless of how many pages deep the session was -- on the theory that stepping back one page at a time through a long search/login session was tedious. That trade was wrong: it meant a single accidental back press (system gesture or the in-app arrow) could silently destroy an entire multi-page browsing session with no way to recover it, and it doesn't match how every other browser or in-app browser view on the platform behaves. Now: go back through the WebView's own page history first (canGoBack()/goBack()), and only close the screen once there's nowhere left to go back to. Both the system back gesture and the in-app top-bar arrow route through the same handleBack(), so they behave identically. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ7ikw2ukGJFTHE3bJS7zL
2026-07-25	Migrate blog.securitymouse.com to its Blogger canonical https URL	Peter Stone
	Its own custom-domain TLS is broken, but it's a Blogger blog under the hood (confirmed via its feed's Blogger-format Atom XML and "Server: GSE" on the homepage) -- Blogger blogs are always reachable at a stable, always-https URL keyed by blog ID regardless of the custom domain's own DNS/TLS setup. Checked whether the other two remaining http feeds from the last migration have a similar way out: they don't. webpolicy.org's feed is dead (last post 2015). bit-player.org was rebuilt on a static generator that no longer exposes a feed at any checked path (/feed, /feed/, /feed.xml, /rss, /atom.xml, or a <link rel="alternate"> on its homepage). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ7ikw2ukGJFTHE3bJS7zL
2026-07-25	Migrate http:// feeds to https:// where it actually works; add feeds as ↵	Peter Stone
	https-only going forward Android blocks cleartext by default (targetSdk 28+), so every http:// feed was failing every single fetch ("CLEARTEXT communication ... not permitted"). Checked each of this user's 9 http feeds live via curl: - 6 work fine over https (5 are a plain scheme swap; divingforpearlsblog.com's own https endpoint redirects through an insecure feedburner hop, so that one points straight at feedburner's https endpoint instead) -- migrated via a new Room migration (v6->v7), rewriting both the feed row and its articles' feedId so read history isn't orphaned. Confirmed live: all 6 now fetch clean with no lastError. - 3 have no usable https at all (bit-player.org: connection refused, no TLS listener; blog.securitymouse.com: broken TLS handshake; webpolicy.org: a certificate that doesn't match the hostname) and are deliberately left alone. Going forward, adding a feed (manually or via OPML import) upgrades a given http:// URL to https:// before using it -- most sites serve identical content either way, and a site with no real https support just fails its very next fetch attempt the normal way instead of silently subscribing to a feed that can never actually update. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ7ikw2ukGJFTHE3bJS7zL
2026-07-25	Text-only bottom bar, re-extract action, fix YouTube thumbnails, verify ↵	Peter Stone
	Stash creds before saving - Bottom bar: Previous/Keep unread/Next are now plain text labels, no icons - Add "Re-download and re-extract" to the overflow menu (ReaderScreen and LinkReaderScreen) to force a fresh fetch + Readability pass on demand, overwriting whatever's cached - Fix a real compile bug in the previous commit's reader-mode-off handler (passed null into a non-null setExtractedContent) via a proper clearExtractedContent() DAO query - YouTube embeds: fixed the broken-image-glyph bug two ways -- (1) an 11-char video-ID regex was accidentally matching a playlist embed's literal "videoseries" placeholder path, building a thumbnail URL for a video that doesn't exist, and (2) Readability's link-density cleanup was discarding the replacement entirely (a bare <a><img></a> reads as an ad/share unit). Restructured as a <figure>/<figcaption> pair -- the same shape a normal captioned photo takes -- confirmed live this survives extraction intact - Stash settings: API key field is now a password field with a show/hide toggle, and "Verify and save" makes a real authenticated request before persisting anything, showing why it failed instead of silently saving bad credentials Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ7ikw2ukGJFTHE3bJS7zL
2026-07-24	Add a "keep unread" skip button between Previous and Next	Peter Stone
	Advances to the next article the same as Next, but without the implicit mark-read that normally comes with moving on -- for "I looked, but I'm not done with this one yet." Verified live: skipping past an article leaves it unread while the queue still advances; regular Next still marks read as before. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ7ikw2ukGJFTHE3bJS7zL
2026-07-24	Collapsible folders, long-press link menu, YouTube thumbnails, strip more ↵	Peter Stone
	Ars sequel chrome - Feed list: folders now collapse (start collapsed, with a per-folder unread count so collapsing doesn't hide "is there anything new") - Long-pressing a link inside an article shows an action menu (open in browser, share, save to Stash, save for later) instead of WebView's default text-selection popup -- confirmed live end to end, including the Stash/save-for-later paths creating a real standalone article - New shared ensureStandaloneArticle() helper (data/ArticleSaving.kt), factored out of ShareReceiverActivity, now also used by the long-press menu - YouTube iframe embeds become tap-to-open thumbnails (JS is off in the reader WebView, so the real player never worked anyway); tapping one goes straight to the YouTube app/browser instead of our own article-extraction pipeline - Fixed back navigation through a chain of links-within-links: each hop was stacking a new backstack entry, so back stepped through the chain one link at a time instead of returning straight to the source article. Confirmed live: A -> link -> B -> link -> C, one back-press now goes straight to A - Extended the <header> chrome-stripping from last round: also strip <footer>, an author bio card, and a "Most Read" trending-stories widget -- confirmed live one of the latter showed up as a giant unrelated photo plus an empty numbered list (its lazy-loaded items never populate in this hidden, off-screen extraction WebView) Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ7ikw2ukGJFTHE3bJS7zL
2026-07-23	Strip <header> chrome before Readability parses; show full article title in ↵	Peter Stone
	reader content - Confirmed live (Ars Technica): a section-kicker badge, the dek/subhead, and an orphaned duplicate hero-image caption were all leaking into extracted content because they live in a <header> Readability doesn't exclude by tag, only deprioritizes in scoring. Strip <header> from the DOM ourselves before handing off to Readability -- a pre-processing decision on our side, not a change to Readability's own algorithm, per instruction not to touch it. - Render the article's full title as a heading at the top of the reader content itself (wrapReaderHtml), not just the top bar, which truncates to one line. This also replaces whatever heading Readability happened to keep in-body, now that <header> (and any <h1> inside it) is stripped pre-parse. - Bump extraction timeout 15s -> 25s: confirmed live, several heavy real-world pages were timing out before onPageFinished ever fired, well short of a real parsing failure. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ7ikw2ukGJFTHE3bJS7zL
2026-07-23	Rebrand to FeeDreader; overflow-menu cleanup; deferred read-marking; ↵	Peter Stone
	folder-organized feed list - Rename app to FeeDreader with an owl launcher icon and a paywall-avoidance note in Settings - Move Open original/Save to Stash into the reader's overflow menu; add Mark unread there too - Only mark an article read when navigating away via Previous/Next, not on open or on back - Saved list no longer crosses out read items; its count includes them - Back from Unread (the root screen) now opens the feed list instead of exiting the app - Feed list: clearer separator above the per-feed list, folder grouping (from OPML categories) with case-insensitive sort, and a virtual "Last fetch failed" section at the top - Reader extraction: cap unsized decorative SVG icons (fixes Ars Technica's giant section-badge icon), force native loading="lazy" images to load eagerly in the hidden extraction WebView, and drop a lightbox's duplicate caption only when a real figcaption sibling exists - Backlog notes on swipe-to-next research, extraction test coverage, and an async-rendered-gallery race confirmed live on Ars Technica Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ7ikw2ukGJFTHE3bJS7zL
2026-07-23	Drop swipe-to-next-article; bottom Previous/Next bar; smaller titles; bug report	Peter Stone
	- Dropped swipe-to-next-article entirely, per explicit instruction. Two different fixes for the gesture interfering with WebView scrolling had already been tried and didn't resolve the reported jerkiness (one even broke swipe outright and was reverted) -- rather than keep tuning gesture detection, removed the gesture altogether. - ReaderScreen: new bottom bar with explicit Previous/Next buttons (disabled at the ends of the article queue), replacing swipe. This is the first slice of the "bottom action strip" backlog item. Verified live: Previous/Next correctly page through the article queue with the right enabled/disabled state at each end. - Smaller title text: reader top bar title (titleMedium, was TopAppBar's default titleLarge) and article list row titles (bodyMedium, was ListItem's default bodyLarge). - New "Report bug" action in the reader's overflow menu: a dialog for a short description, which gets bundled with the article's title/URL/id, feed id, reader-mode state, and save/Stash state into one text block copied to the clipboard on confirm (verified live, including the "Copied to clipboard" confirmation) -- enough to reproduce an issue in the tungsten emulator without needing live device access. - BACKLOG.md: marked the done slice of the bottom-strip item, added a note on the scroll-jerkiness investigation so far (two ruled-out theories) since swipe removal may or may not affect it -- worth a fresh look now that nothing intercepts touches above the WebView at all.