client: a scroll step before the viewport reply arrives starts from the stale offset #164

New issue

Closed

opened 2026-10-18 13:31:57 +09:00 by natsukium · 0 comments

natsukium commented

2026-10-18 13:31:57 +09:00

Owner

Split from #158.

Problem

The client computes every scroll step from the shadow's acknowledged offset (crates/felis-client/src/app_methods.rs apply_scroll / scroll_by_rows), not from the request it has already sent or queued. Until the daemon's ViewportState reply arrives:

End followed by LineUp: End queues Viewport(0), the shadow still says N, LineUp computes N + 1. The replaceable Input::Viewport slot (crates/felis-client-core/src/outgoing.rs) can replace the queued End with it, so the view never reaches live; if End already left, LineUp returns the view to N + 1 before the live reply lands.
Two quick LineUps from N both request N + 1, losing a step.

Found in design review of #158; it exists on main independently of the anchoring there.

Expected

A scroll step starts from the latest viewport intent the client has issued, not only the acknowledged one: End then LineUp requests 1 relative to the live bottom; two LineUps from N land at N + 2.

Notes

Clearing a pending intent needs to tell the reply to a request from a ViewportState the daemon ships on its own (output growth while browsing, eviction, a screen switch), which suggests a request sequence echoed in ViewportState, a wire addition.

Split from #158. ## Problem The client computes every scroll step from the shadow's acknowledged offset (`crates/felis-client/src/app_methods.rs` `apply_scroll` / `scroll_by_rows`), not from the request it has already sent or queued. Until the daemon's `ViewportState` reply arrives: - End followed by LineUp: End queues `Viewport(0)`, the shadow still says `N`, LineUp computes `N + 1`. The replaceable `Input::Viewport` slot (`crates/felis-client-core/src/outgoing.rs`) can replace the queued End with it, so the view never reaches live; if End already left, LineUp returns the view to `N + 1` before the live reply lands. - Two quick LineUps from `N` both request `N + 1`, losing a step. Found in design review of #158; it exists on main independently of the anchoring there. ## Expected A scroll step starts from the latest viewport intent the client has issued, not only the acknowledged one: End then LineUp requests `1` relative to the live bottom; two LineUps from `N` land at `N + 2`. ## Notes Clearing a pending intent needs to tell the reply to a request from a `ViewportState` the daemon ships on its own (output growth while browsing, eviction, a screen switch), which suggests a request sequence echoed in `ViewportState`, a wire addition.

natsukium added the

Area/client

Kind/Bug

labels

2026-10-18 13:32:07 +09:00

natsukium referenced this issue from a commit

2026-10-18 15:31:17 +09:00

grid, protocol, daemon, client, docs: keep a scrolled-back view on its lines as output arrives

natsukium referenced this issue

2026-10-18 15:31:26 +09:00

grid, protocol, daemon, client, docs: keep a scrolled-back view on its lines as output arrives #169

natsukium referenced this issue from a commit