Fix: Added robust keyboard visibility detection using WindowInsetsCompat.

[Scapesfear]

Purpose / Description

Ensures that when the keyboard is open, pressing back first closes the keyboard instead of collapsing the search view, using robust keyboard visibility detection with WindowInsetsCompat

Fixes

• Fixes Pressing back to dismiss keyboard closes search #17913

Approach

Implemented WindowInsetsCompat to accurately detect keyboard visibility. On back press, if the keyboard is open, it is hidden first instead of collapsing the search view..

How Has This Been Tested?

Samsun Galaxy F23 5G
https://github.com/user-attachments/assets/cc33384c-768f-4bf3-b82b-935c2019f68c

Checklist

Please, go through these checks before submitting the PR.

• You have a descriptive commit message with a short title (first line, max 50 chars).
• You have commented your code, particularly in hard-to-understand areas
• You have performed a self-review of your own code
• UI changes: include screenshots of all affected screens (in particular showing any new or changed strings)
• UI Changes: You have tested your change using the Google Accessibility Scanner

[MrTheMech]

Hey @Scapesfear ,

I tested the implementation, and it works perfectly! 🚀 The fix effectively prevents the keyboard from popping up when returning to searched cards.

One small improvement: Instead of naming the variable isCardBrowserReloaded, we can replace it with shouldClearSearchFocus for better readability and clarity.

I've attached a video of my test:
https://github.com/user-attachments/assets/5d2f647d-0b79-4b02-a3ae-65e789acff98

[Scapesfear]

One small improvement: Instead of naming the variable isCardBrowserReloaded, we can replace it with shouldClearSearchFocus for better readability and clarity.

Hi @MrTheMech, thanks for suggestion, actually i named the variable so, because when we come back from any activity to the caller, the caller gets reloaded and thus I named it isCardBrowserReloaded.

[mikehardy]

Seems like it should work - one curiosity (that may result in no change...) about choice of method to close the soft keyboard

[mikehardy]

Out of curiosity, why not use this since we are already using the WindowInsetsCompat: https://developer.android.com/reference/kotlin/androidx/core/view/SoftwareKeyboardControllerCompat#hide()

It may be that using the InputMethodManager directly is the best way, but I'm curious if that was a considered decision or not, and if so, why using InputMethodManager vs the Compat is best

[Scapesfear]

Hi @mikehardy,

hide() is essentially an abstraction over the InputMethodManager approach. Here's the snippet that shows what it does under the hood:

@Override
void hide() {
    if (mView != null) {
        ((InputMethodManager) mView.getContext()
                .getSystemService(Context.INPUT_METHOD_SERVICE))
                .hideSoftInputFromWindow(mView.getWindowToken(), 0);
    }
}

I opted for the InputMethodManager method because when I searched for ways to hide the keyboard, this was the most popular solution. I tested it, and it reliably works across various Android versions.

Also, note that the alternative approach using

view.windowInsetsController?.hide(WindowInsets.Type.ime())

is deprecated.