Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Search bar] Should stop listening for back callbacks when detached from window #4176

Closed
grahammendick opened this issue May 13, 2024 · 1 comment
Assignees

Comments

@grahammendick
Copy link

Description: Views that are detached from the window shouldn’t respond to predictive back gestures. Take a tabbed view, for example, with open search bar results on the second tab. When on the first tab the search bar should no longer receive the back callback because it prevents the user from closing the app (see video below).

Screen.Recording.2024-05-13.at.17.47.50.mov

Expected behavior: The gesture back on the first tab should close the app instead of being received by the search bar. In the video below you can see the gesture back correctly closes the app when the search bar results aren’t open.

Screen.Recording.2024-05-13.at.17.47.00.mov

Source code: The screenshot shows the search bar receives the back callback even though it isn't attached to the window.

Screenshot 2024-05-13 at 17 53 22

Minimal sample app repro: The 2 videos above were taken from the minimal sample repo. I built it from the “Bottom Navigation Views Activity” template in Android Studio and added a search bar to the dashboard tab. The steps to recreate the bug are in the README.

Android API version: 34

Material Library version: 1.12.0

Device: Pixel 6 Pro simulator

@grahammendick grahammendick changed the title [Search bar][Bottom sheet] Should stop listening for back callbacks when detached from window [Search bar] Should stop listening for back callbacks when detached from window May 14, 2024
grahammendick added a commit to grahammendick/navigation that referenced this issue May 14, 2024
All navigation stacks have the same fragment manager. A fragment manager can only have one primary navigation stack because that's the one that receives the gesture back. So dynamically set the primary stack when the stack is attached to the window.

The recommended way to handle nested stacks is for them to [share a fragment manager](https://developer.android.com/guide/fragments/fragmentmanager#multiple-back-stacks). Then save and restore the back stack when tabs change. But no need for that for now.

Should one day support different fragment managers on ancestor stacks so that could possibly have the child handle gesture back and then the ancestor when child stack is gone. Could probably also do this without different fragment managers by updating primary to the ancestor when child goes.

Also found a [material component bug](material-components/material-components-android#4176) while investigating nested stacks.
@dsn5ft dsn5ft self-assigned this May 14, 2024
@dsn5ft dsn5ft closed this as completed in d13bfdf May 15, 2024
@grahammendick
Copy link
Author

@dsn5ft Thanks for working on this!
Don't you have to start listening for back callbacks again when the SearchView is attached to window? That's equivalent to tabbing back to the dashboard tab and then gesture back

kendrickumstattd pushed a commit that referenced this issue Jun 20, 2024
…in onAttachedToWindow() and remove modal for accessibility state in onDetachedFromWindow()

Fixes an issue where nothing is focusable in TalkBack after removing SearchView, due to the modal for accessibility behavior

Resolves #4176

PiperOrigin-RevId: 644038017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants