Sign up
View stargazersSign up

[Bug][Mobile] Opening a thread from home search leaves the list filtered when you come back#26321

opened16d agobyKkevvykevwin

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

  1. On the iPhone app's home screen, open search and type a query.
  2. Tap one of the matching threads to open it, then reply or just read it.
  3. Go back to the home thread list.

Expected behavior

Opening a thread from the search results clears the search, so the full thread list is back when you return. Desktop already works this way: picking a search result in the sidebar clears the query before it navigates (selectThreadSearchResult calls clearThreadSearch() in apps/web/src/components/Sidebar.tsx).

Actual behavior

The list is still filtered by the old query. To see your other threads again you have to reopen search and clear the text yourself, every time you use search to find a thread.

In the code, the iPhone home list keeps the query in the workspace threads tab state (HomeRouteScreen.tsx, searchQuery / setSearchQuery). handleSelectThread navigates to the thread but never resets that query, and HomeScreen's selectThread doesn't either.

This is close to #22388, which was fixed by clearing the query when you tap Cancel. That fix doesn't help here, because opening a thread from the results never goes through Cancel.

On iPad split view the list stays visible next to the open thread, so keeping the query there seems reasonable. This report is about the phone layout, where the thread covers the list.

Impact

Minor bug or occasional failure

Version or commit

Seen on the current iOS app. Code references are from main @ feb49e78.

Environment

iPhone, T3 Code iOS app

Workaround

Reopen search and clear the query by hand after coming back from the thread.

Kkevvykevwin16d ago
Synced from GitHub

A few things I ran into while trying a fix locally, in case they save whoever picks this up some time. File references are from main @ feb49e78.

Clear after Home is covered, not on tap. Home stays on screen until its transitionEnd with closing: true (Stack.tsx wires this to recordHomeTransitionEnd in home-route-visibility.ts). If the query is cleared in handleSelectThread right after selectDetail, the list swaps to the full unfiltered list and jumps to the saved scroll offset while it's still sliding away. The whole list also rebuilds during the push. On devices without Liquid Glass, and on the Duo folded, the header search bar also unmounts mid-transition. Deferring the clear to that closing transitionEnd, and dropping the intent if Home reappears first (for example a cancelled back swipe), avoids all of that.

Use the cancel action, not an empty query. In workspace-tabs-state.ts, cancel sets the query to "", sets searchMode back to "resting", and restores the pre-search scroll offset. Dispatching { type: "query", query: "" } leaves searchMode active, so restoreSearch in WorkspaceToolbar.ios.tsx reactivates the native search bar when Home reappears. The toolbar's own cancelSearch also calls recordScrollOffset before dispatching, so a shared helper would keep the two paths from drifting.

The native search field keeps its own text. restoreSearch only calls setText(tab.query) when the tab isn't resting. After a cancel that didn't come from the search bar itself, the field can still show the old query when you come back. Clearing the field when the tab is resting with an empty query fixed that, and it does nothing after a normal Cancel, since the field is already empty then.

Two smaller things:

  • Split-view check: layout.usesSplitView alone isn't quite the right test for "the list stays beside the thread". On the Duo unfolded in portrait, primarySidebarOverlaysContent is true and the overlay hides after selection, so the thread covers the list there too.
  • Pending tasks: they show up in filtered results (useThreadListV2 matches pendingTask.title against the query). Opening one goes through selectThreadRoute instead of handleSelectThread, so it needs the same treatment.

I only checked this with unit tests and typecheck, not on a device.