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

Chip input always receives focus first #22

Open
majid701 opened this issue Feb 23, 2018 · 9 comments
Open

Chip input always receives focus first #22

majid701 opened this issue Feb 23, 2018 · 9 comments

Comments

@majid701
Copy link

I have noticed that the chips input always receives the focus first in an activity. Is this the desired behaviour? I want to be able to disable this functionality so I can handle the focus order in my activity differently.
We could remove the focus from the chips element programmatically afterwards but then the user would notice the cursor switching from one element to another and this is bad user experience.

Has anyone noticed this? Any solution?

thanks

@najmsheikh
Copy link

Yea would really love to know if disabling autofocus is possible. I've tried most possible solutions from SO (that worked with EditTexts) but no game :/

@tylersuehr7
Copy link
Owner

Thanks for posting this issue!

This problem seems to be happening in the ChipsAdapter whenever the edit text is readjusted to fit the width of the screen in the onGlobalLayout() callback because it calls the requestFocus() on the edit text itself.

I could put a check in there like, 'if auto focus disabled then don't request focus', but that might effect the functionality of the auto sizing though. I'll attempt it then thoroughly test it, but you'd just need to set that in the view's XML layout like app:autoFocusDisabled="false" so that it knows you don't want it to request focus every time it's resized to fit the screen.

@bliveinhack
Copy link
Contributor

Any updates about this. because it's very weird and doesn't let users fill other inputs .
Any temporary fix will be helpful ..

Regards.

@majid701
Copy link
Author

majid701 commented May 8, 2018

@bliveinhack this is my workaround for now. Try it and let me know if you find a better one.
Basically what I'm doing is execute some code with a small delay (50 milliseconds) after the activity has started which clears the focus from the tagview and requests focus on the view you want to receive focus first instead.

(KOTLIN)

override fun onStart() {
    super.onStart()
    // Work around to correct focus issue on tag field
    Timer().schedule(50){
        runOnUiThread {
            // itemTags is ur tagview
            itemTags.clearFocus()
            // the view in your activity/fragment you want to give focus first
            itemTitle.requestFocus() 
            // this is optional but helpful to show keyboard (doesn't work always and on all devices)
            showKeyboardOnView(itemTitle)
        }
    }
}


private fun showKeyboardOnView(view: View) {
    val imm = getSystemService(Context.INPUT_METHOD_SERVICE) as InputMethodManager
            imm.showSoftInput(view,
            InputMethodManager.SHOW_IMPLICIT)
}

@bliveinhack
Copy link
Contributor

Thanks for workaround.

I'm ended up forking repository and make ChipEditText public so that i can clear focus on scrolling.
here is Jitpack https://jitpack.io/#bliveinhack/chips-input-layout/2.4.1
and Repo https://github.com/bliveinhack/chips-input-layout

Regards.

@DonMat
Copy link

DonMat commented Jun 15, 2018

Did you try to set

android:focusable="false"
or
android:focusableInTouchMode="false"

It works fine for me.

@Nivas78
Copy link

Nivas78 commented Jan 17, 2019

It is not working for me

@XandiVieira
Copy link

Any solution? I'm facing the same issue

@kumarJadhav1993
Copy link

in chipAdapter.java add
// Request focus
if (mDataSource.getSelectedChips().size() > 0) {
mEditText.requestFocus();
mEditText.setFocusableInTouchMode(true);
}

this code.
if chips are not empty then only focus otherwise don't focus.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants