mirror of
https://github.com/navidrome/navidrome.git
synced 2026-11-05 17:58:37 +01:00
50633f839d* fix(ui): anchor detail pages to the top when opened from a list React Router keeps the previous page's scroll offset, so opening an album from a scrolled list started the detail page mid-song-list. Artist pages had the same bug; it just shows less because the artist list is rarely long enough to scroll far. Keyed on the record id rather than mount, so detail-to-detail navigation (an album's artist link) resets too, and so the scroll waits for the record instead of firing against an empty page. * feat(ui): remember each route's scroll offset A hook that saves window.scrollY per history entry and, on navigation, tops a pushed route or returns a popped one to where it was. Keyed on location.key so back and forward each restore their own offset, and bounded because history entries are not. Callers pass their own readiness: restoring before the rows render leaves the document too short, so the browser clamps to the top and the offset is lost with no error to show for it. * refactor(ui): fold scroll-to-top into route scroll restoration useScrollToTop only ever forced the top, so it fixed opening a detail page from a scrolled list and did nothing for the return trip: coming back to the list landed wherever it happened to be. The new hook covers both, and its readiness argument carries over the reason the old one keyed on the record id - waiting for the record rather than firing against an empty page. * feat(ui): restore the album list's position when returning to it The list is the page worth remembering: scrolling a long way to find an album and landing back at the top is the annoyance the detail-page scroll fix could not reach. Mounted as a pass-through around the List's child rather than beside it, because React Admin calls Children.only on List children and clones that one child with the list props - which is also how this reads loaded/total to wait for rows. * fix(ui): key scroll restoration on the route, not location.key Hash history never assigns location.key - history.js calls createLocation with an undefined key and warns that it cannot carry state - so every route collapsed into one slot. The detail page's own scroll listener then overwrote the list's saved offset with 0, and going back restored that 0. Only the scroll-to-top half worked, which is what made it look fine. Keyed on pathname+search instead. The spec that would have caught this asserts two routes keep separate offsets; the previous ones mocked the router and so only ever confirmed the assumption. * refactor(ui): tidy up scroll restoration after review Four cleanups, none changing behaviour: ScrollRestorer read loaded/total off whatever props React Admin happened to clone in. useListContext is the contract for those values and is already used three times elsewhere, including further down this same file; the clone payload is an implementation detail that would fail silently if it ever changed. The restore runs in a layout effect now. A passive effect is flushed after paint, so an image-heavy grid was painted at the old offset and then jumped. MAX_ENTRIES matches the naming every other module-level cap in common/ uses. The per-instance guard against re-restoring was deletable with a green suite, so it now has a spec: readiness flickering on one route must not scroll twice. * fix(ui): resolve media queries on the first render MUI defaults useMediaQuery and withWidth to SSR-safe two-pass rendering: the first render reports the wrong breakpoint and a layout effect corrects it. Navidrome is client-only, so every mount paints a layout it immediately reflows. Album tiles render without their artist line and grow 14px when it arrives, and react-admin's own buttons paint labelled before collapsing to icons, which together grew the album list 79px right after a scroll restore and dragged the position with it. Setting noSsr on the theme reaches react-admin's internals too. withWidth needs its own option because it gates on a mount flag rather than on the media query. * fix(ui): keep restoring the scroll offset until it sticks A single scrollTo assumes the page is already at its final height. It often is not: the artist page reports ready as soon as its cached header record renders, while the albums below are still loading, so the browser clamps the offset to the top of a viewport-tall document and it is lost with no error. The restore now retries until the offset lands, yielding as soon as the position moves somewhere we did not put it. Keying that on input events instead breaks the trackpad back-swipe, whose wheel momentum keeps firing through the restore window. Offsets are also committed when leaving the page rather than on every scroll. Tearing the page down collapses the document and snaps to the top, and a live listener recorded that clamp over the offset being left behind. * refactor(ui): tidy up scroll restoration after review Folds the offset commit into the scroll tracker's own cleanup now that the tracker ignores the collapse snap, so one effect does what two did. Skips scheduling the retry loop when the first scrollTo already landed, and only pays for the scrollHeight read on scroll events that reach the top, since that is the only case the guard can fire. The theme hook's own prefers-color-scheme query runs above the ThemeProvider carrying the new prop, so it needs noSsr passed directly or the auto theme still renders dark first and flips. Also lifts the repeated fake-timer fixture in the specs into one helper and restores real timers from afterEach, so a failing assertion no longer leaves them installed for every later spec. * fix(ui): bank the scroll offset before the next page tops itself Committing the offset from the scroll listener's passive cleanup ran too late. The incoming page scrolls to the top in its own layout effect, and the outgoing page's listener is still attached at that moment, so it recorded that 0 over the offset being left behind. Whether it did depended on when the browser dispatched the scroll event relative to React's passive flush, which made returning to a detail page lose its position intermittently. Moving the commit back into a layout cleanup makes it deterministic: React runs those in the mutation phase, before the incoming page's layout effects. The scrollHeight guard in the listener went with it, since it only covered the case where the incoming page was shorter than the viewport and the ordering covers all of them. |
||
|---|---|---|
| .. | ||
| actions | ||
| album | ||
| artist | ||
| audioplayer | ||
| common | ||
| dataProvider | ||
| dialogs | ||
| i18n | ||
| icons | ||
| layout | ||
| library | ||
| missing | ||
| personal | ||
| player | ||
| playlist | ||
| plugin | ||
| radio | ||
| reducers | ||
| share | ||
| song | ||
| store | ||
| subsonic | ||
| themes | ||
| transcode | ||
| transcoding | ||
| user | ||
| utils | ||
| App.jsx | ||
| authProvider.js | ||
| config.js | ||
| consts.js | ||
| eventStream.js | ||
| eventStream.test.js | ||
| hotkeys.js | ||
| index.css | ||
| index.jsx | ||
| routes.jsx | ||
| setupTests.js | ||
| sw.js | ||
| swNavigation.js | ||
| swNavigation.test.js | ||
| useChangeThemeColor.jsx | ||
| vite-env.d.ts | ||