PageUp/PageDown skips transcript hidden behind the thread composer #5718

Summary

In the thread view, the prompt composer (and its banners) is a position: sticky; bottom: 0 element inside the timeline scroll container, so the container's clientHeight includes the area the composer covers. Native PageUp/PageDown advances by roughly clientHeight * 0.875, so each page skips the strip of transcript that was hidden behind the composer. Reading a long agent response with the keyboard loses lines between pages.

Versions and environment

• bb 0.46.1, installed as the packaged bb-app (web surface), NixOS.
• Also reproduced from source at ee36dfda78 (desktop-v0.46.1-72-gee36dfda78), Linux, Node 22.23.3.
• Browser: Chromium 151.0.7922.71 (headless and normal).
• Default data dir ~/.bb; server 127.0.0.1:38886; host daemon 127.0.0.1:38887. Single machine, no Connect, no custom ports.

Steps to reproduce

1. Open a thread whose transcript is taller than the pane, e.g. a long agent answer.
2. Click into the timeline text so focus is inside the scroll container. The composer must not be focused.
3. Press PageDown twice, then PageUp once.
4. Compare the last visible line of one page with the first visible line of the next.

Notes:

• With focus on body (nothing in the timeline focused), Chromium does not scroll the timeline at all, so focus inside the scroll container is required.
• Space uses the same page math and is affected too.
• Did not reproduce on a page whose content is shorter than the pane (nothing to scroll).

Expected vs actual

Measured in Chromium 151 against the 0.46.1 build, thread pane 709px tall:


[data-page-scroll-viewport] top 48, bottom 757, clientHeight 709
[data-scroll-footer]        top 554, bottom 757, insideScrollViewport: true, position: sticky
footerOverlapsViewport:     203


The scroll container is 709px tall, but the composer covers its bottom 203px, so only 506px of transcript is visible. `PageDown` is computed from the 709px scrollport (Chromium pages by `clientHeight * 0.875`), so the next page starts below the previous page's visible bottom and the strip that was under the composer is skipped.

Synthetic confirmation that Chromium pages by `clientHeight`, independent of any overlay: a 437px scroll container advanced 382px on `PageDown` (`437 * 0.875`).

Expected: `PageUp`/`PageDown` advance by the visible transcript height (scrollport minus the composer), so consecutive pages overlap slightly and no lines are skipped.

Evidence

• Code at ee36dfda78:
  • https://github.com/get-bb/bb/blob/ee36dfda78/apps/app/src/components/ui/bottom-anchored-scroll-body.tsx#L1019-L1052 — the footer is rendered inside scrollContentRef as sticky bottom-0, inside the overflow-y-auto scroll port.
  • https://github.com/get-bb/bb/blob/ee36dfda78/apps/app/src/components/ui/page-shell.tsx#L35-L52 — renderStaticFooter wrapper.
  • https://github.com/get-bb/bb/blob/ee36dfda78/apps/app/src/components/thread/embedded-chat/EmbeddedThreadChat.tsx#L184-L196 — the thread timeline uses PageShell scrollBehavior="bottom-anchor".
• How measured: Chromium DevTools Protocol getBoundingClientRect()/clientHeight on [data-page-scroll-viewport] and [data-scroll-footer], and Input.dispatchKeyEvent for PageDown/PageUp.

What you ruled out

• Not a focus bug: with the timeline focused the container does scroll; it scrolls by the wrong amount.
• Not a provider issue: pure frontend scroll math, reproduces on the built-in UI regardless of provider or model.
• Not windowing/virtualization: the same scroll port is used for a small thread.
• Not a duplicate: searched open and closed issues for PageDown, PageUp, composer scroll, paging timeline, keyboard scroll composer, sticky composer timeline; nothing covers paging vs the composer overlay. Closest is Fit the upward mentions menu inside the visible pane #4673 (mentions menu clipping), which is a different symptom.
• Not the content growing mid-measurement: the geometry above is stable on an idle thread.

AGENT GENERATED

Suggested priority and effort (optional)

No response

Checks

• I reproduced this on the latest release or on main, or I say above that I could not.
• I searched open and closed issues for the same problem.
• If an agent wrote this, the body ends with > AGENT GENERATED and links the thread or report.