Summary
The global search bar in the TopBar advertises itself as searching titles, artists, and albums (placeholder: "Rechercher un titre, un artiste, un album...") but the dropdown only ever renders a flat list of tracks. There is no way to land on an album page or an artist page from the search, even though the underlying FTS index already covers all three.
Reported by a user via email.
Reproduction
- Type an album name (e.g. "Dark Side of the Moon") into the top search bar.
- The dropdown shows only individual tracks from that album.
- There is no "Albums" section, no "Artists" section, and clicking any row plays the track — there is no way to navigate to the album detail page or the artist detail page.
Expected behavior
Spotify / Apple Music style sectioned results:
- Top result (best match across all entities)
- Artists — clicking opens
ArtistDetailView
- Albums — clicking opens
AlbumDetailView
- Titles — clicking plays the track (current behavior)
Root cause
The backend is fine — track_fts already indexes title + album_title + artist_name (migrations/profile/20260411120000_initial.sql:322), so typing an album or artist name already returns matching rows. The limitation is purely in the frontend:
src/components/layout/TopBar.tsx stores a single Track[] (line 73) populated exclusively from searchTracks / searchTracksAdvanced (src/lib/tauri/track.ts).
- The dropdown (lines 533–562) renders one section, and the only click handler is
playTracks(...) (line 205) — no setActiveView('album-detail' / 'artist-detail') path exists.
- The placeholder string (
src/i18n/locales/fr.json:213 and equivalents in the other 16 locales) therefore misrepresents what the feature actually does.
Suggested fix
- Backend — add
search_albums(query, limit) and search_artists(query, limit) Tauri commands, probably in src-tauri/crates/app/src/commands/browse.rs, backed by the existing repository traits with LIKE/canonical_name matching (FTS is track-scoped today, so a small LIKE '%q%' against album.canonical_title and artist.canonical_name is the lowest-friction path). Return a small payload: { id, title, artwork_hash, ... } matching the shapes already used by AlbumGridCard / ArtistGridCard.
- Frontend wrappers — add
searchAlbums / searchArtists in src/lib/tauri/browse.ts.
- TopBar dropdown — restructure into sections (Top result + Artists + Albums + Titles), each with its own click handler:
- Artist row →
setActiveView('artist-detail') with the artist id
- Album row →
setActiveView('album-detail') with the album id
- Track row →
playTracks (unchanged)
- Keep one debounced fan-out (
Promise.all([searchTracks, searchAlbums, searchArtists])) so the three sections appear together.
Scope
Frontend (TopBar refactor + i18n placeholder is already accurate so no string change needed) + two new backend commands. No DB migration required since track_fts and the canonical-name columns already exist.
Summary
The global search bar in the
TopBaradvertises itself as searching titles, artists, and albums (placeholder: "Rechercher un titre, un artiste, un album...") but the dropdown only ever renders a flat list of tracks. There is no way to land on an album page or an artist page from the search, even though the underlying FTS index already covers all three.Reported by a user via email.
Reproduction
Expected behavior
Spotify / Apple Music style sectioned results:
ArtistDetailViewAlbumDetailViewRoot cause
The backend is fine —
track_ftsalready indexestitle + album_title + artist_name(migrations/profile/20260411120000_initial.sql:322), so typing an album or artist name already returns matching rows. The limitation is purely in the frontend:src/components/layout/TopBar.tsxstores a singleTrack[](line 73) populated exclusively fromsearchTracks/searchTracksAdvanced(src/lib/tauri/track.ts).playTracks(...)(line 205) — nosetActiveView('album-detail' / 'artist-detail')path exists.src/i18n/locales/fr.json:213and equivalents in the other 16 locales) therefore misrepresents what the feature actually does.Suggested fix
search_albums(query, limit)andsearch_artists(query, limit)Tauri commands, probably insrc-tauri/crates/app/src/commands/browse.rs, backed by the existing repository traits withLIKE/canonical_namematching (FTS is track-scoped today, so a smallLIKE '%q%'againstalbum.canonical_titleandartist.canonical_nameis the lowest-friction path). Return a small payload:{ id, title, artwork_hash, ... }matching the shapes already used byAlbumGridCard/ArtistGridCard.searchAlbums/searchArtistsinsrc/lib/tauri/browse.ts.setActiveView('artist-detail')with the artist idsetActiveView('album-detail')with the album idplayTracks(unchanged)Promise.all([searchTracks, searchAlbums, searchArtists])) so the three sections appear together.Scope
Frontend (TopBar refactor + i18n placeholder is already accurate so no string change needed) + two new backend commands. No DB migration required since
track_ftsand the canonical-name columns already exist.