Finding the bug
Like any real open source developer, I use Firefox as my main web browser so I’m pretty heavily invested into the Mozilla ecosystem. This means that my choice of password manager is Firefox Lockwise since it integrates well into Firefox. It also has some great and simple apps for use on mobile that also supports autofill on newer versions of android. I use this app often as it allows you to generate secure passwords on forms and store them safely on your phone, reducing the risk included in re-using more memorable passwords across sites.
The bug I found was present in any input fields in the app and looked like this:
The input text handles on EditText elements in the android app seemed to have borders and backgrounds behind them. I had seen this bug a long time about but chalked it up to being an android bug since I’m using an older version of android on my device. It wasn’t until about a week into Hacktoberfest that I realized I hadn’t seen it anywhere else and saw it as an opportunity to get another pull request in.
When I first decided to take a look at the issue I clone the repo and just started digging around. I had never worked on any Android projects before so I found it a little bit overwhelming. After about a week I put the project aside in order to focus on getting in some other pull requests only to forget about it entirely. I continued on with my other courses and PRs only to find myself in the last week before Hacktoberfest ended and needing to get something done. I tried to find some issues that I could work on cloning everything in sight but never finding a project I wasn’t either over my head in, or another one-liner I didn’t think I’d learn much from.
So, I came back to the Lockwise issue with a bit more sense of urgency which I think made me buckle up and just tackle the issue head-on. But I wasn’t confident enough to post the issue or get started on Github (a mistake on my part looking back).
Actually getting started
I needed to download Android Studio and set up a virtual device for testing which was actually simpler than I thought. After getting things set up I looked up some tutorials and documentation regarding android development and was pleasantly surprised at how many resources are out there for learning Android development. After using the Layout Inspector tool from Android Studio and some impressive Google-fu, I narrowed the issue down to the fact that somehow a background property was being inherited by the Android Text handles somewhere along the line.
Using concepts I knew
I consider myself to be pretty comfortable with UI and UX design using CSS on web but having never worked on an Android project before I was admittedly out of my element. Nonetheless having encountered similar issues in CSS before I knew I should trace the style hierarchy up to the top and just do some trial and error until I changed a property which also changed the handle background colour. This is where things got pretty frustrating.
After a few days of changing individual styles in the Android Studio visual layout editor to no avail, I did some more research before committing to giving up and doing another one-liner.
This time, I discovered some Stackoverflow posts mentioning similar issues that confirmed what I suspected when it came to a parent element causing the handle to inherit the background. More importantly, I learned that the cause of this can be found in the styles.xml file where themes can be declared along with regular styles. The importance was the distinction between the two. A theme would take precedence over a style applied on a child element, meaning that my hours and days of changing styles around to find the culprit would have never worked.
Instead, by looking at the backableToolbar theme in style.xml and changing the background colour to another, I was able to change the background of the Text Handle. This meant, however, that a transparent background couldn’t simply be added to the EditText inside the parent backableToolbar via a style or XML tag because the backableToolbar’s theme would override it.
<style name="EditTextHandlesReset"> <item name="android:background">@android:color/transparent</item> <item name="android:colorControlActivated">@color/violet_70</item> </style>
<EditText android:id="@+id/filterField" android:layout_width="0dp" android:layout_height="match_parent" android:layout_weight="1" android:hint="@string/search_logins" android:background="@null" android:textSize="20sp" android:textColor="@android:color/white" android:textColorHint="@color/white_60_percent" android:textCursorDrawable="@null" android:inputType="textAutoComplete" tools:ignore="Autofill" android:theme="@style/EditTextHandlesReset"/>
By creating a style in styles.xml and setting it as a theme on the element, we can override the existing background to transparent (and fix the handle colour while we’re at it). This plus a couple other fixes to avoid the same issues app-wide were implemented and submitted as a PR.
What I learned
Well, for starters, I should have never waited until completing the fix to submit an issue & PR. That was a silly mistake on my part that I’ve learned from. I also learned how to work with Android projects and look forward to doing so in the future.