Repository navigation
fix(zbugs-rune): keep a new issue's row in view at the list's top - #196
Merged
Merged
Conversation
Creating an issue opened it in the issue pane, but its row in the list stayed out of view, so no row showed highlighted: Rune's virtual rows hold the reader's top row in place when a new row comes above it, even at offset 0, so the new issue landed just above the viewport. An issue created or reopened in another app did the same. A reorder (an issue edited elsewhere rising to the top) slides rows without anchoring, so it never hid. The list now records its scroll offset (`El::on_scroll_offset`) and, at its top, scrolls back to 0 when new rows arrive, as zbugs-gpui's `keep_scroll_anchor` and zbugs-swift's list do. Scrolled down, it still holds its rows in place. e2e.sh creates an issue from the New Issue sheet with the list at its top and checks its row is on screen and highlighted; it fails without the fix (the row sits at y=0, above the list's viewport at y=53). Amp-Thread-ID: https://ampcode.com/threads/T-01a1d634-9fac-7561-a14a-d552061a006c Co-authored-by: tmm <tmm@tmm.dev>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
In zbugs-rune, creating an issue opened it in the issue pane, but no row in the list showed highlighted. The new issue's row was there, just out of view above the list's top.
Cause. Rune's virtual rows keep the top row in place when a new row comes in above it, even with the list at offset 0 (Rune's own test
a_page_prepended_above_the_reader_at_the_top_keeps_them_in_place). A new issue sorts first, so it landed just above the viewport while it showed as selected. The same thing happened with an issue created or reopened in another app. A reorder, where an issue edited elsewhere rises to the top, slides the rows without anchoring, so it never hid. That's why the recording shows it only after issues were created.Fix. The list records its scroll offset (
El::on_scroll_offsetinto aLive<f32>). When new rows arrive and the list is at its top, it scrolls back to 0, the way zbugs-gpui'skeep_scroll_anchorbehaves ("At the top, the list stays at the top") and zbugs-swift's list does in the recording. A scrolled-down list still holds its rows in place.Checked on a Mac against zbugs' backend (
apps/zbugs-swift/server), headless with--snap:e2e.shgets a new run that creates an issue and checks that its row is on screen and highlighted. It fails without the fix and passes with it; all 12 checks pass. That run uses--snapbecause Rune anchors to the row it drew, and without drawing the bug doesn't show.cargo fmt --check,clippy -D warnings, andcargo testpass.