Repository navigation
fix(web): expanding stacked notices no longer scrolls a working thread - #20086
derektrimm wants to merge 1 commit into
Conversation
github-actions
Bot
added
vouch:unvouched
![macroscopeapp[bot]](https://avatars.githubusercontent.com/in/900172?s=60&v=4){kind=small}
ApprovabilityVerdict: Approved at Macroscope's review found this PR approvable — This is a localized web bug fix that prevents expanded stacked notices from increasing the timeline reservation and causing a later scroll jump. Existing behavior remains unchanged when the optional adjustment is absent, and the new calculation is covered by focused tests. You can add or adjust custom eligibility rules. Learn more. |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info
📝 Walkthrough
Merge Risk: ⚪ Minimal · up to
|
| Check name | Status | Explanation | Resolution |
|---|---|---|---|
| Linked Issues check |  |
Issue [#19880] requires the end-following timeline to move with notice expansion so the last message is not covered, for idle and working threads. This change subtracts expanded notice height from the… |
Implement the [#19880] expansion behavior that keeps the last message clear for idle and working threads. Add automated coverage for expansion, the next streamed row, and collapse. |
-
Check name Status Explanation Title check The title clearly and concisely describes the main fix: expanding stacked notices no longer causes a working thread to scroll unexpectedly. Description check The description explains the problem, intended behavior, implementation, scope, verification steps, observed results, limitations, and test status. It also includes recordings and identifies the issue… Out of Scope Changes check The changes stay within the [ #19880] composer notice and timeline layout scope.ComposerBannerStackadds the measurement marker,ChatViewexcludes expanded notice growth from the reservation, and …Full details: Description check
-
Explanation
The description explains the problem, intended behavior, implementation, scope, verification steps, observed results, limitations, and test status. It also includes recordings and identifies the issue. The description does not include before-and-after screenshots or an explicit maintainer approval comment, but it is otherwise sufficiently complete for this focused bug fix.
Full details: Out of Scope Changes check
-
Explanation
The changes stay within the [
#19880] composer notice and timeline layout scope.ComposerBannerStackadds the measurement marker,ChatViewexcludes expanded notice growth from the reservation, andcomposerFooterLayout.test.tscovers the inset calculation.
-
Full details: Linked Issues check
-
Explanation
Issue [
#19880] requires the end-following timeline to move with notice expansion so the last message is not covered, for idle and working threads. This change subtracts expanded notice height from the reserved inset. The added test confirms that the inset remains stable while notices expand. The implementation therefore removes the late jump after a new row, but it intentionally leaves the last rows covered during expansion. The direct issue requirement remains unmet.Resolution
Implement the [
#19880] expansion behavior that keeps the last message clear for idle and working threads. Add automated coverage for expansion, the next streamed row, and collapse.
- Fix all pre-merge checks with AI
✨ Finishing Touches
-
🧪 Generate unit tests (beta)
-
- Create a new PR
-
- Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
Comment @coderabbitai help to get the list of available commands.
00fe53e to
e7ed45a
Compare
Hovering the composer's notice stack grows the overlay, and the timeline reserved that growth as footer space. The thread did not move at once, but the next row re-pinned it to the new end, jumping by the expanded height. The reservation now leaves out how far the stack grew past its collapsed height, so working threads behave like idle ones: the expanded notices cover the last rows until the pointer leaves. Fixes pingdotgg#19880
e7ed45a to
5004d02
Compare
This branch has not been deployed
1 participant
Fixes #19880
Hovering the notice stack's peek strip expands the stacked notices inside the composer overlay.
publishComposerOverlayHeightmeasured that growth and added it to the timeline's footer reservation.TIMELINE_MAINTAIN_SCROLL_AT_ENDignores footer growth, so nothing moved at first, but the next row on a working thread re-pinned the timeline to the new end and the thread jumped up by the expanded height. As triaged on the issue, the covering is intended and only the late jump is the bug.The reservation now leaves out how far the stack grew past its collapsed height (the
min-h-3that holds the peek strip), rounded once so it equals the collapsed overlay.ComposerBannerStackmarks its container withdata-composer-banner-stackfor this, the same way the model strip is found. Working threads now behave like idle ones: the expanded notices cover the last rows until the pointer leaves, and nothing moves on expand, on the next row or on collapse.Checked in a dev web build (
vp run dev) on Linux, headless Chromium at 1280x640, with a Claude thread runningsleep 3; echo progress Nsteps. Switching the project's branch mid-turn stacked a "Branch changed" notice behind/usage-limits. I scrolled to the end, hovered the peek strip and sampled the timeline'sscrollTopand scroll range every 100 ms:Recordings (14 s each, hovering the stack while rows stream in): before, on main and after, on this branch.
The new case in
composerFooterLayout.test.tsfails on main and passes here. Typecheck and lint pass forapps/web.Not checked: the three-account
/usage-limitsstack from the issue, since this machine has one account; the stacked notice here was the compact branch notice, so the measured jump was 31 px rather than 360 px. Mobile renders its own composer and does not use this stack.Made with Claude Opus 5.5 in Claude Code, running in T3 Code.