diff options
Diffstat (limited to 'BACKLOG.md')
| -rw-r--r-- | BACKLOG.md | 40 |
1 files changed, 40 insertions, 0 deletions
@@ -81,3 +81,43 @@ scrolling still feels jerky now that nothing above the WebView is doing any gesture detection at all -- if it still does, the cause is something else (WebView rendering/compositing itself, the emulator's software rendering not reflecting real-device feel, etc.), not gesture interception. + +**Confirmed on a real device (2026-07):** scrolling measurably improved +once swipe-to-next was dropped. So any future attempt to bring back a +swipe-to-next gesture needs to be judged against that baseline -- it must +not regress scroll feel back to the pre-removal state. Two arbitration +approaches already tried and failed (see above); a fresh approach (e.g. +a much larger/edge-only swipe hit target that never competes with +vertical scroll gestures at all, rather than trying to disambiguate axis +mid-gesture) would need to be prototyped and felt out live, not just +reasoned about in code review. + +## Extraction test coverage for WHT / Ars Technica (not yet built) + +**Motivation:** both sites' Readability extraction has needed repeat fixes +(lazy-loaded images, doubled captions, paywall-targeted un-hide) and each +fix so far has been diagnosed by hand against a single live article rather +than against a standing set of known-tricky pages. Reported as still +inconsistent after multiple rounds of fixes -- regressions are easy to +reintroduce without something to check against. + +**Rough shape (not yet built):** save a handful of representative fixture +HTML pages from each site (lazy-image markup, a paywalled article, one +with duplicate captions) alongside the expected extracted output, and run +them through `ReaderExtractor`'s pipeline in an instrumented test (it needs +a real WebView to run Readability.js, so this can't be a plain JVM unit +test) on every change to the extraction/paywall-unhide logic, instead of +re-fetching a live article by hand each time. + +**Also confirmed live (2026-07):** the same Ars Technica article extracted +with its gallery photos included on one run and without them on another, +with no code change in between. Ars's gallery section appears to render +in client-side JS some time after the page's initial HTML document load +(`onPageFinished`, which is when `ReaderExtractor` currently runs +Readability) -- so whether it's finished by the time our script executes +is a real race, not something the `loading="lazy"` fix (also added this +round) addresses. A proper fix likely means waiting for the page to go +network-idle (or a short fixed settle delay) before parsing, which trades +against `TIMEOUT_MS` and adds latency to every single extraction -- worth +deciding deliberately rather than bolting on, so left for this backlog +item rather than this round's quick fixes. |