FeeDreader — personal Android RSS reader https://git.terst.org/feedreader.git/atom?h=master 2026-08-22T01:08:42+00:00 2026-08-22T01:08:42+00:00 Peter Stone thepeterstone@gmail.com 2026-08-22T01:08:42+00:00 urn:sha1:a5f728648dda46e84959a4568a3f04d5cc7bb11f 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-07-25T04:03:11+00:00 Peter Stone thepeterstone@gmail.com 2026-07-25T04:03:11+00:00 urn:sha1:19bfb97fb30b7bfc861d1d17c3b406e6157f6d02 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-23T01:59:14+00:00 Peter Stone thepeterstone@gmail.com 2026-07-23T01:59:14+00:00 urn:sha1:3914ba17608884a6fa8614b9058752e0c1c0d94f - FeedParser: a feed with a literal empty <guid>/<id> element (confirmed live: a Mother Jones entry) produced an ArticleEntity with id = "" -- the fallback chain only checked for null, not blank, so an empty-but- present tag passed straight through. An empty-string primary key broke Navigation Compose's route matching and crashed on tap ("tapping this article crashes the app"). Fixed both RSS and Atom paths to treat blank the same as null before falling back to a link-based id. Schema v5 migration deletes any row already on-device with the bad id; it'll come back with a real, hash-based id on the next fetch of that feed. Verified live: zero blank-id rows after the migration and a fresh fetch, no crash. - BrowserScreen: back (both the system gesture and the in-app arrow) now always closes the screen directly, rather than stepping through in-page WebView history first. Reported live as not making sense for multi-page browsing (search results -> article -> another link, etc.) -- you'd have to tap back that many times just to leave. There's no separate in-page-back affordance now, matching how every other screen in this app behaves. - Tried moving swipe-to-next-article detection off Compose's gesture system entirely (a passive native OnTouchListener on the WebView, never consuming) on the theory that Compose's gesture arbitration was the source of reported scroll jerkiness. Reverted after confirming live that swipe stopped working at all with that approach -- a worse regression than unproven jerkiness. Back to the known-working Compose-based detector; the jerkiness complaint itself is still open. - BACKLOG.md: added bug-report-button, smaller-title-text, and bottom-action-strip-with-auto-hide notes. 2026-07-22T18:35:06+00:00 Peter Stone thepeterstone@gmail.com 2026-07-22T18:35:06+00:00 urn:sha1:e804e7a77a6cac048d5f6edeac0a339ca89e4d40 Deliberately not a paywall-bypass mechanism -- that space (archive.today-style proxies, "Bypass Paywalls" extensions) is legally grey, adversarial toward publishers, and constantly breaking. Instead: - BrowserScreen: a real interactive mini-browser (JS + DOM storage on, ordinary navigation, no Readability interception) for the two cases where the user needs to actually USE a page rather than read it. Reached from a new overflow menu on the article reader: - "Log in to this site" opens the article's own URL there so the user can sign into a site they already subscribe to. Needs no extra plumbing: Android's CookieManager is one process-wide store shared by every WebView in the app, so a session cookie set here is picked up automatically by the reader's (JS-off) extraction WebView on the next visit to that domain -- same as a normal browser remembering you're signed in. - "Find another source" runs a web search on the article's title in the same browser, so the user can pick a different, non-paywalled outlet covering the same story themselves -- plain search/discovery, not circumvention. Verified live: search opened a real, interactive Google results page with working title-bar sync; back navigation (via BackHandler, goBack() when the WebView has history, else pop the screen) returned cleanly to the article.