Flaky: thread-list-big WebKit scroll loads 60 threads, not ≤45 #378
Labels
No labels
area/ci
area/desktop
area/packaging
area/protocol
area/reading
area/ui
area/web
area/writing
kind/bug
kind/feature
kind/infra
kind/request
needs/user
parked
perf
security
upstream
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
littlefox/neokom#378
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The WebKit variant of thread-list-big.spec ("scrolling up a big thread list loads a page at a time") fails now and then on the desktop profile: first scroll loads 60 threads, budget 45 (
webkit: scroll 1 loads a page, not the channel), then times out on retry. Seen in run #687 (the first nightly full run on main, 2026-10-28) and as flaky in #668. Not tied to a change in those runs. To look into: whether WebKit's scroll event coalescing triggers two page loads.Merged in #389. I couldn't reproduce it locally (20/20 WebKit runs, also with all CPUs busy), so the fix removes the mechanism: an older page now loads only after the reader's own scroll since the last one (place-keeping scrolls don't count). All scroll-related specs pass on all profiles. Reopen if a nightly shows it again.