Search from the volume list, and type into the field without a second tap

Two papercuts in the search added in the previous commits, both found by using it.

BrowserContent decided between the volume list and a folder listing on path == null alone, so on the "Storage" screen the roots were drawn over the answer: a search everywhere from there was computed and never shown. The switch now also asks whether a search is running - its results are full paths, so nothing has to be open first - and the volume list is drawn only when there is neither a folder nor a search.

Opening the field on that screen also switches the scope to everywhere, since "this folder" has no meaning with no folder open and the field's hint would otherwise invite a query that could never match. The view model makes the same fallback on its own, so a query typed from the volume list is answered everywhere whether or not the scope was switched.

Tapping the search action now focuses the field and brings the keyboard with it, waiting for the frame the field appears in, because focusing a node that is not attached yet does nothing. Asking the user to tap the box they just opened was a tap of pure ceremony.

The wide layout no longer focuses the first root while a search is running, which would have moved the detail pane under the results.

289 JVM tests, lint clean, release APK builds. No device pass: /dev/kvm is still absent from this environment, so the emulator cannot start - the focus change in particular is verified by compile and by reading the API contract, not by watching a keyboard appear.
This commit is contained in:
2026-10-16 23:26:44 +02:00
parent d2183ebc79
commit 90806fa3cc
6 changed files with 118 additions and 49 deletions
+14
View File
@@ -12,6 +12,20 @@ upload needs a **higher `versionCode`** than every previous upload.
### Fixed
- **Searching needed a volume to be open first, and needed a second tap to be typed into.** Two
papercuts in the feature added above, both found by using it. `BrowserContent` decided between
the volume list and a folder listing on `path == null` alone, so on the "Storage" screen the
roots were drawn *over* the answer: a search everywhere from there was computed and never
shown. The switch now also asks whether a search is running — its results are full paths, so
nothing has to be open first — and the volume list is drawn only when there is neither a folder
nor a search. Opening the field there also switches the scope to everywhere, because "this
folder" has no meaning with no folder open and the field's own hint would otherwise invite a
query that could never match; the view model makes the same fallback on its own, so a query
typed from the volume list is answered everywhere whether or not the scope was switched. And
tapping the search action now focuses the field and brings the keyboard up with it: it waited
for the frame the field appears in, because focusing a node that is not attached yet does
nothing, and asking the user to tap the box they just opened was one tap of pure ceremony.
- **The progress notification never appeared on Android 13 or newer, and five permissions were
declared that the app never used.** `StorageAccessPolicy.missingPermissions` returned an empty
list from API 33 on the reasoning that "all files access" is a special permission rather than