StripeEditText view's text color going transparent

[eddiecrawford]

Summary

When typing in to the StripeEditText fields, then deleting characters and reentering, the entire edit text sometimes goes transparent:

Code to reproduce

                <com.stripe.android.view.CardNumberEditText
                    android:id="@+id/etCardNumber"
                    style="@style/ModelC_Body"
                    android:layout_width="match_parent"
                    android:layout_height="wrap_content"
                    android:imeOptions="actionNext"
                    android:inputType="number"
                    android:maxLength="19"
                    android:nextFocusUp="@id/etZipCode"
                    android:nextFocusLeft="@id/etZipCode"
                    android:nextFocusForward="@id/etExpirationDate"
                    android:nextFocusDown="@id/etExpirationDate"
                    android:nextFocusRight="@id/etExpirationDate"
                    tools:targetApi="o"
                    tools:hint="Card Number" />

Android version

API 26 (8.0)

Installation method

Maven / Gradle

SDK version

8.0

[csabol-stripe]

@eddiecrawford thanks for the report! We're going to investigate this internally and get back to you :)

[mshafrir-stripe]

@eddiecrawford I wasn't able to reproduce this on device or emulator. Can you provide more details on what device you are testing on, what app, and whether it always reproduces?

[eddiecrawford]

@mshafrir-stripe Interesting 🤔
I'm able to reproduce on different APIs (23, 26, & 28). We're just wrapping Stripe's EditText views in a TextInputLayout and showing TIL errors accordingly. We also have a TextWatcher attached to these EditText views AND a OnFocusChangeListener, so we can validate on every key press. I'm able to reproduce on the ExpiryDateEditText class as well.

We're wrapping the EditTexts in a TIL like this:

            <com.google.android.material.textfield.TextInputLayout
                android:id="@+id/tilCardNumber"
                style="@style/Theme.TextInputLayout"
                android:layout_width="match_parent"
                android:layout_height="wrap_content"
                android:layout_marginStart="@dimen/size_8"
                android:layout_marginTop="@dimen/size_18"
                android:hint="@string/stripe_card_number"
                ibotta:errorTextAppearance="@style/Theme.TextInputLayoutError"
                ibotta:layout_constraintTop_toBottomOf="@id/tilZipCode">

                <com.stripe.android.view.CardNumberEditText
                    android:id="@+id/etCardNumber"
                    style="@style/ModelC_Body"
                    android:layout_width="match_parent"
                    android:layout_height="wrap_content"
                    android:imeOptions="actionNext"
                    android:inputType="number"
                    android:maxLength="19"
                    android:nextFocusUp="@id/etZipCode"
                    android:nextFocusLeft="@id/etZipCode"
                    android:nextFocusForward="@id/etExpirationDate"
                    android:nextFocusDown="@id/etExpirationDate"
                    android:nextFocusRight="@id/etExpirationDate"
                    tools:targetApi="o"
                    tools:hint="Card Number" />

            </com.google.android.material.textfield.TextInputLayout>

[eddiecrawford]

Found where it's occurring. When setShouldShowError(true) is called via afterTextChanged on a StripeEditText view, it sets the error color to the default value. Since the mErrorColor was never instantiated in our flow (we never set the error color, and in fact don't want to since we're using a TextInputLayout to show our errors), it defaults to 0. Which is why it's dissapearing, but then reappearing once the number is valid.

setShouldShowError:173, StripeEditText (com.stripe.android.view)
afterTextChanged:213, CardNumberEditText$1 (com.stripe.android.view)
sendAfterTextChanged:9770, TextView (android.widget)
afterTextChanged:12522, TextView$ChangeWatcher (android.widget)
...

I can get around this by manually setting the mErrorColor via StripeEditText#setErrorColor to our desired default text color (the same as our valid color).

Maybe don't use the default value of 0 if it's never set?
It also seems like the mDefaultErrorColorResId value is not taken into account here?

It would also be awesome if we could set this error color via XML :)

@mshafrir-stripe / @csabol-stripe

[mshafrir-stripe]

@eddiecrawford thanks for the thorough investigation. I put up a PR to fix the issue - #989. In a future PR I'll look into specifying error color via XML.