Repository navigation
[Bug]: Mobile: @ picker lists threads under a "Files" heading, mixed in with files #15659
Description
Before submitting
- I searched existing issues and did not find a duplicate.
- I included enough detail to reproduce or investigate the problem.
Area
apps/mobile
Steps to reproduce
- Open a thread in the mobile app, in an environment with other threads.
- Type
@plus a few letters that match both thread titles and file names, e.g.@Rev.
Expected behavior
Threads and files are distinguishable at a glance: separate "Threads" and "Files" groups, or at least a heading that does not claim everything is a file.
Actual behavior
One flat list under a single "FILES" heading. Up to five thread matches come first, each marked only by a small trailing "Thread" label that truncates on longer titles ("Thre…"); files follow with no separator. The empty state has the same problem: it reads "No matching files or folders." even though threads were searched too.
Impact
Cosmetic issue on its own. It becomes a real obstacle combined with the picker not scrolling on Android (#15658): the thread rows fill the visible area and push every file out of reach.
Version or commit
main @ 4ee6bfd
Environment
Android 16 emulator (Pixel), T3 Code Dev client built from the commit above. The code is shared with iOS; not tested there.
Screenshots
Cause
apps/mobile/src/features/threads/use-composer-command-menu.ts returns threads and paths as one array for the path trigger:
return [...threadItems, ...pathSearch.entries.map(...)];and ComposerCommandPopover.tsx picks the heading and empty text from the trigger kind alone (groupLabel: path → "Files"; emptyText: "No matching files or folders."), so it has no notion of the list containing two kinds of item.
Related
#15156 covers the @ search closing on a space, which is why a multi-word thread title cannot be typed to narrow this list.
Activity
juliusmarminge commentedon Oct 4, 2026
Note
Grok responding on behalf of Julius.
Triage
Thanks for this, @tris203, and for linking it to #15658, which is what turns this into a real blocker.
What I found
On
mainat4ee6bfd50e, a typed@query puts up to five thread-title matches first and then files, on both mobile and web. A bare@is still a plain file picker.matchComposerThreadItemsis shared, and the web composer comments that title matches lead the list because they're more specific than fuzzy path hits. Web doesn't have separate "Threads" and "Files" sections either.Within that, two things look wrong on mobile:
ComposerCommandPopover.tsxpicks both from the trigger kind alone. Forpath,groupLabelreturns "Files" and the empty state says "No matching files or folders." Web uses the same empty sentence, and its list is labeled "Files and folders" for assistive tech, but it has no visible "Files" banner. Once the query has also searched threads, "Files" over those rows is misleading, including when nothing matches.description: "Thread"frommatchComposerThreadItems, next to a message icon (text.bubble, or the Tabler message icon on Android). The title isshrink-0with no max width, so a normal title takes the whole row and the description gets cut off. Web caps the title atmax-w-[45%], so "Thread" stays readable there.Likely fix area
groupLabeland the empty text inComposerCommandPopover.tsx. They could take into account whether thread matches are in the list.A maintainer will decide on the fix direction.