littlefox/neokom

Watch

Fork 1

Thread list: scrolling up a big channel loads a page, not all of it #316

Merged

littlefox merged 4 commits from issue-314-thread-list-cascade into main

2026-10-23 22:27:43 +00:00

littlefox commented

2026-10-23 19:01:04 +00:00

Owner

Closes #314

On the desktop app, scrolling up a big channel's thread list loaded the whole channel and hung. Rows waiting for their card are a few pixels tall, so each new page sat right at the top and triggered the next. WebKit, which the desktop app uses, also doesn't keep the reader's place when content comes in above (it has no scroll anchoring).

Older threads load only after the list has been shown at its end and the previous page's cards are drawn (or tried).
The shared window script keeps the place itself, by the row's number, with the browser's scroll anchoring off. The channel chat uses the same script, so it gets the WebKit fix too.
Seed: "Många trådar", 400 threads, member Uno Uppåt.
thread-list-big.spec.ts runs in Chromium and in WebKit. Before the fix, the first scroll to the top loaded all 400 threads (WebKit loaded 300 on opening). After, each of three scrolls loads 15 and the row at the top stays on screen.
Channel/thread specs, all profiles, with 30 ms latency: 31 passed. Lint passes all three ways; devserver tests pass.
Also D-065 (#315).

🤖 Generated with Claude Code

https://claude.ai/code/session_01XJW2ocwLunyaLiUwCBHEP8

Closes #314 On the desktop app, scrolling up a big channel's thread list loaded the whole channel and hung. Rows waiting for their card are a few pixels tall, so each new page sat right at the top and triggered the next. WebKit, which the desktop app uses, also doesn't keep the reader's place when content comes in above (it has no scroll anchoring). - Older threads load only after the list has been shown at its end and the previous page's cards are drawn (or tried). - The shared window script keeps the place itself, by the row's number, with the browser's scroll anchoring off. The channel chat uses the same script, so it gets the WebKit fix too. - Seed: "Många trådar", 400 threads, member Uno Uppåt. - `thread-list-big.spec.ts` runs in Chromium and in WebKit. Before the fix, the first scroll to the top loaded all 400 threads (WebKit loaded 300 on opening). After, each of three scrolls loads 15 and the row at the top stays on screen. - Channel/thread specs, all profiles, with 30 ms latency: 31 passed. Lint passes all three ways; devserver tests pass. - Also D-065 (#315). 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01XJW2ocwLunyaLiUwCBHEP8

littlefox added 1 commit

2026-10-23 19:01:04 +00:00

Thread list: scrolling up a big channel loads a page, not all of it

perf / perf (pull_request) Has been skipped

Details

ci / check (push) Successful in 10m16s

Details

ci / desktop (push) Successful in 15m28s

Details

ci / e2e (push) Failing after 38m6s

Details

51a1e504ec

The user's desktop app hung scrolling up "Inlägg åt mig" (7 000 posts)
in its thread list. Older threads load when the top comes near, and a
page's rows are a few pixels until their cards come: all near the top,
so the page before loaded at once, and the one before that, to the
channel's first post, with a card fetched for every thread. In WebKit
(the desktop app, Safari) it was worse: no scroll anchoring, so even
drawn rows coming in above left the reader at the top.

Older threads now load only once the list has been shown at its end and
the page before is drawn (or its cards tried), and the window script
keeps the place itself, by the item's number (the list's items are
taken out and put back), with the browser's anchoring off. The channel
chat shares the script, and gets the WebKit fix too.

New seed: "Många trådar", 400 threads, for Uno Uppåt. New spec in
Chromium and in WebKit: three scrolls to the top load a page each, and
the row at the top stays on screen. Before: 400 rows on the first scroll.

Also D-065 for #315 (mark a channel read, the presentation in reach).

Closes #314

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

littlefox added 1 commit

2026-10-23 20:05:25 +00:00

Thread list spec: read the top row when scrolling, after the list settles

perf / perf (pull_request) Has been skipped

Details

ci / check (push) Successful in 9m35s

Details

ci / desktop (push) Successful in 15m56s

Details

ci / e2e (push) Failing after 36m31s

Details

ff8f3dc737

On CI a page was still coming in when the spec noted the top row, so
the row it then looked for was a page further down, off screen; the
app kept its place. Wait until no rows come for a second, and note the
top row and scroll in one step.

Refs #314

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

littlefox added 2 commits

2026-10-23 21:46:53 +00:00

Window script: keep the place exactly, whatever moves above 00eee22d02

The big-list spec failed now and then on CI (and here, two runs in five
in WebKit): the place drifted. Anchor on the first item that starts on
screen (one peeking in at the top still grows when its card comes, and
pushed the rest down); keep the place when the list's items are put
back, not only on resize, and give a missing anchor a frame to come
back; and watch each item's size, since one growing above while another
shrinks below leaves the list's size as it was. Since: 12 of 12 there,
and three full runs of the channel specs here. The spec says which
scroll failed and where the row went.

Refs #314

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

Merge remote-tracking branch 'origin/main' into issue-314-thread-list-cascade

perf / perf (pull_request) Has been skipped

Details

ci / check (push) Successful in 9m42s

Details

ci / desktop (push) Successful in 15m33s

Details

ci / e2e (push) Successful in 40m17s

Details

90fb4e6736

littlefox referenced this pull request

2026-10-23 22:06:01 +00:00