Infeasible
Status Update
No update yet.
Comments
al...@android.com
m3...@gmail.com
Is it confirmed to be a real bug or should we make the dirty job manually? In case of bug, when is it planned to be fixed?
ch...@google.com
Even if it is a bug, it doesn't mean that it will be fixed. This is low priority.
ch...@gmail.com
Hmmm, why is this low priority ?
I find this bug to be very annoying especially with the new "character count" property that was added in 23.1.0,
The user cannot even see the count because of the keyboard :/
I find this bug to be very annoying especially with the new "character count" property that was added in 23.1.0,
The user cannot even see the count because of the keyboard :/
ch...@google.com
#4: There are no APIs which allow us to alter the focus area so that the counter/error is displayed.
we...@gmail.com
Possible fix:
Get the height of the error/counter fields.
Use that value as a negative topMargin for the same fields. (negative margins should be ok for LinearLayouts)
Use that value as a bottom inset for the EditText background. The background should be an inset drawable.
Get the height of the error/counter fields.
Use that value as a negative topMargin for the same fields. (negative margins should be ok for LinearLayouts)
Use that value as a bottom inset for the EditText background. The background should be an inset drawable.
da...@gmail.com
I wonder what sort of twisted criteria was used to classify this bug as "low priority"
ch...@google.com
#7: Read
m0...@gmail.com
We need a fix for this it's a useless message for the user if it can't be seen right away. Not everyone can see colors, so the red underline is not accessible and not effecive enough to indicate an error.
ch...@google.com
#9: Read
bo...@gmail.com
maybe a fix could be to put the counter not below the EditText, but on the same line, or floating above?
m0...@gmail.com
I fixed this by scrolling the view a couple pixels. Worked magic. Hopefully they will extend their API to conquer this issue.
bo...@gmail.com
You scroll it after it gets focused?
m0...@gmail.com
I scroll it after I get isErrorEnabled(true). You also have to scroll back when there is no error message or it will keep scrolling up. It's kinda messy but works. You could also just scrollUp whenever it's focused.
bo...@gmail.com
Thanks! Nice workaround!
ab...@gmail.com
is there any update on this issue?
da...@gmail.com
As usual Android team addresses their issues with amazing speed, professionalism and competence.
m0...@gmail.com
They won't fix this, it's infeasible. Just don't make errors people!
je...@hotmail.com
Here is Google's work around: https://gist.github.com/siyamed/e7276009121d775c0d74ea7d6b01fc25 according to Google I/O'19 Use this in place of your TextInputEditText.
Description
Version used: 22.2.0
The TextInputLayout contains an EditText which in turn receives the input from the user. With TextInputLayout introduced with the Android Design Support Library we're supposed to set the error to the TextInputLayout holding the EditText rather than the EditText itself. When writing the UI will be focused on only the EditText and not the whole TextInputLayout which can lead to the keyboard covering the error.
In the following GIF notice that the user has to remove the keyboard first to see the error message. This in combination with setting IME actions to move on using the keyboard leads to really confusing results. I've attached the GIF or you may view it here:
I'm only using the standard code to reproduce this, nothing weird but I can provide the code if you want it.
What I think should happen is that the focus area takes into account if the view has the "errorEnabled" attribute set to true and if so makes sure that not only the input field is visible but also the area for the error text.