Status Update
No update yet.
Comments
ng...@gmail.com
pa...@google.com
pa...@google.com
Hi I checked the issue, Cannot see the issue on N5, However did you put some check for setError ?
Would it be possible to get a complete standalone test app that reproduces this behavior?
Would it be possible to get a complete standalone test app that reproduces this behavior?
ca...@gmail.com
[Comment deleted]
ca...@gmail.com
Hi,
I also have this issue.
My application uses multiple fragments and a lot of them have text input layouts with setError(true).
I found that when I clear the keyboard on back stack change via:
public static void hideKeyboardToken(Activity activity) {
InputMethodManager imm = (InputMethodManager)activity.getSystemService(Activity.INPUT_METHOD_SERVICE);
View view = activity.getCurrentFocus();
if (view != null) imm.hideSoftInputFromWindow(view.getWindowToken(),0);
}
All of the text input layouts will be rendered as red.
When I stop hiding the keyboard all of the text input layouts behave as expected. (But the keyboard remains persistent when changing fragments.)
SDK Versions:
minSdkVersion 16
targetSdkVersion 22
compileSdkVersion 23
buildToolsVersion "23.0.2"
Phone: Samsung Galaxy S5
I also have this issue.
My application uses multiple fragments and a lot of them have text input layouts with setError(true).
I found that when I clear the keyboard on back stack change via:
public static void hideKeyboardToken(Activity activity) {
InputMethodManager imm = (InputMethodManager)activity.getSystemService(Activity.INPUT_METHOD_SERVICE);
View view = activity.getCurrentFocus();
if (view != null) imm.hideSoftInputFromWindow(view.getWindowToken(),0);
}
All of the text input layouts will be rendered as red.
When I stop hiding the keyboard all of the text input layouts behave as expected. (But the keyboard remains persistent when changing fragments.)
SDK Versions:
minSdkVersion 16
targetSdkVersion 22
compileSdkVersion 23
buildToolsVersion "23.0.2"
Phone: Samsung Galaxy S5
sr...@gmail.com
I have the same issue. Created a sample project to simulate the same.
https://github.com/pollux-/DesignLibIssue
pa...@google.com
We will have a look at the issue and provide more information on this as it becomes available
sr...@gmail.com
[Comment deleted]
Description
Version used: >=23.0.x
Theme used:
Devices/Android versions reproduced on: api 16->23
As already commented at
Hello,
Is the following issue known?
* Following bug is existing in the library (at least in version 23.0.1, 23.1.0, 23.1.1): the 1st TextInputLayout causes a strange behavior. As a workaround while waiting for a fix from Google, I had to create a "dummy" 1st TextInputLayout (and put it as android:visibility="gone").
* How to reproduce the error:
- Start-up the app.
- In activity A, make the 1st TextInputLayout appears error with error text below red-line (=setError).
- Change to activity B then go back to activity A.
- Now in activity A, red-line(s) of all TextInputLayout(s) unexpectedly appear (without error texts). Very strange behavior!!!
Thx!
#18 You should open a new bug report with example code.
And to answer your question, yes! I saw that once but had no idea how to reproduce it.